2.150.2 Configuration Management (CM) Process

Manual Transmittal

August 19, 2020

Purpose

(1) This transmits revised IRM 2.150.2, Configuration Management, Configuration Management (CM) Process.

Material Changes

(1) Separated the procedures between Software Configuration Management and ITIL/ITSM Configuration Management

(2) Separated the swim lane diagrams between Software Configuration Management and ITIL/ITSM Configuration Management

(3) Expanded the procedure for Software Configuration Management

(4) Expanded the procedure for ITIL/ITSM Configuration Management

(5) Added instructions for standard Agile audit

(6) Various editorial changes

Effect on Other Documents

IRM 2.150.2 dated December 10, 2019, is superseded.

Audience

The Configuration Management Process is applicable to all Information Technology (IT) organizations, contractors, and other stakeholders having responsibility for configuration, management, oversight, and successful day-to-day operations of the IRS IT enterprise hardware, software, and applicable documentation.

Effective Date

(08-19-2020)

Nancy Sieger
Acting Chief Information Officer

Program Scope and Objectives

  1. Purpose. This IRM section describes the formal process for implementing the requirements of the Configuration Management (CM) process. It provides an operational definition of the major components of the process and how to perform each step in the process. This document also describes the logical arrangements of steps that are essential to successfully completing the process and achieving its desirable outcome. Configuration Management is a systems engineering process for establishing and maintaining consistency of a product’s (i.e., software application) performance, functional, and physical attributes with its requirements, design, and operational information ensuring consistency among physical and logical assets in an operational environment. Configuration Management is also one of the components in the Information Technology (IT) Service Support under the IT Infrastructure Library (ITIL) framework. It is an IT Service Management (ITSM) process and its primary goal is to identify, maintain, and verify information on IT configuration assets, or configuration items (CIs), in a Configuration Management Database (CMDB) that is required to deliver an IT Service. It covers the identification, recording, and reporting of IT components, including their versions, constituent components and relationships. Items that should be under the control of Configuration Management include hardware, software, and associated documentation. Additionally, where IT Security and IT Operations meet is where it blends together the key practices and establishes a security-focused Configuration Management, such as vulnerability assessment, remediation and configuration assessment. For the purposes of this document, the process scope and objective for this Configuration Management is primarily based on supporting the software development and operations environment.

  2. Audience. The CM Process is applicable to all Information Technology (IT) organizations, contractors, and other stakeholders having responsibility for configuration, management, oversight, and successful day-to-day operations of the IRS IT enterprise hardware, software, and applicable documentation.

  3. Policy Owner. Demand Management & Project Governance (DMPG), under Enterprise Operations, Information Technology.

  4. Program Owner. DMPG is responsible for overseeing the IT CM Program that is responsible for the process and providing guidance. Each IT organization is responsible for establishing an internal or local CM process for managing their procedures based upon this IT CM Process.

  5. Primary Stakeholders. IT organizations having responsibility for establishing an internal or local CM process that issue instructions to employees are stakeholders in the IT CM Program.

  6. Contact Information. To recommend changes or to make any suggestions to this IRM section, email the IT CM Program: it.cm.process@irs.gov

Background

  1. Information systems are typically dynamic, causing the system state to change frequently because of upgrades to hardware, software, or modifications to the surrounding environment in which a system resides. Industry standards and best practices such as:

    • Institute of Electrical and Electronic Engineers (IEEE) Standard for Software Configuration Management in Systems and Software Engineering

    • Software Engineering Body of Knowledge (SWEBOK)

    • ITIL Service Transition 2011: Service Asset and Configuration Management

    • International Organization for Standardization/International Electrotechnical Commission (ISO/IEC) 20000-1:2018 Information Technology - Service Management (ITSM) - Part 1: Service Management System Requirements

    • National Institute of Standards and Technology Special Publications 800-128 Guide for Security-Focused Configuration Management

    including those issued by the Government Accountability Office and the Office of Management and Budget, stress that information systems (e.g., general support systems, major applications, and minor applications) must document and assess the potential impact that proposed system changes may have on the operational processes and security posture of the system. The IT industry best practices recognize this as an essential aspect of effective system management, as well as being part of the continuous monitoring and maintenance of security accreditation of Federal systems.

  2. Configuration Management is a critical control for ensuring the integrity, security, and reliability of the Internal Revenue Service (IRS) information systems. Absent a disciplined process for controlling configuration changes, management cannot be assured that its systems will operate as intended, or that systems’ maintenance will be performed in a cost-effective or timely manner.

Process Definition

  1. Process Description. The information set below describes the characteristics of the CM process.

    • Configuration Management is the process responsible for providing accurate and complete configuration information about software and infrastructure components, including their attributes and relationships, to support other software engineering and service management processes, such as Change Management and Release Management.

    • Businesses require quality IT services to be provided in an economical manner. To be both efficient and effective, all organizations need to have control of their IT services and infrastructure.

    • Configuration Management provides a model of a service's infrastructure or the entire infrastructure by identifying, managing, maintaining and verifying the CIs in existence, their attributes and their relationships with other CIs and the services they enable and support.

  2. Process Goal. The goal is to provide accurate information on the current state of the software, the attributes of IT service related components, and their relationships to enhance the effectiveness of the other software development and service management processes. This is accomplished through the identification, control and verification of those items declared to be within the scope of the process. The key to this process is the identification of the relationships that exist among CIs.

  3. Process Objectives. Process objectives describe material outcomes that are produced or achieved by the process. The following is a list of objectives for this process:

    • Help provide accurate assessment of the risk and impact of a change to a CI.

    • Improve the assessment of the impact of a CI failure by readily identifying the services that it supports.

    • Provide accurate configuration information to other software development and service management processes.

    • Provide a snapshot of a known state of the IT environment or baseline of CIs.

    • Create a standard method for introducing, updating and tracking components or aggregated CIs in the IT environment.

    • Provide a standard automated technology and location for storing information about CIs.

    • Ensure that all changes to the software and infrastructure, CIs or component CI that need to be managed are reflected on the software libraries and repositories, such as a CMDB.

  4. Disciplines. Configuration Management is performed within the context of the 5 common disciplines that are applicable in development, operations, and security environment, as illustrated in the figure below. Although Configuration Management has a shared goal and objective in identifying, managing, and controlling the CIs across the environments, its purpose and application is entirely different.

    • Under the software development environment, Configuration Management ensures that the development and release processes are controllable and repeatable through identification, tracking, and protecting the project’s deliverables or products from unauthorized change.

    • Under the operational environment, Configuration Management ensures the integrity of configurations required to control the services and IT infrastructure by establishing and maintaining accurate and complete CI records in the CMDB.

    • Under the security environment, Configuration Management ensures management and control of secure configurations for an information system to enable security and facilitate management of risk.


    The following figure illustrates the 5 Common Disciplines.

    Figure 2.150.2-1

    This is an Image: 60767001.gif

    Please click here for the text description of the image.

  5. Configuration Item. A configuration item (CI) is a component of a service or system that can be identified as a self-contained unit for purposes of change control and identification. A CI can be a primitive (single) component or an aggregate (collection) of other CIs. The level at which a CI is considered primitive or aggregate is decided by the system in which it is created, maintained, and managed. The table below describes the common types of CIs and defines whether they are in-scope or out-of-scope of the IT CM Process and whether the CIs are in-scope of the IT CMDB.

     
    CI Type CM Process
    (In-Scope or Out-of Scope)
    IT CMDB
    (In-Scope)
    Data (data collections and structures)
    • Structured Data (database)

    • Unstructured Data (emails, text, document, etc.)



    In-Scope
    Out-of-Scope


    No
    Documentation In-Scope No
    Facilities (locations such as data centers) In-Scope Yes
    File (such as a configuration file) In-Scope No
    Hardware
    • Tier I System (i.e., mainframes)

    • Tier II System (i.e., servers)

    • Tier III System (i.e., micro-computer such as desktops, laptops, mobile devices, etc.)



    In-Scope
    In-Scope
    Out-of-Scope


    No
    Yes
    Metadata (such as database schema) In-Scope No
    Network Devices and Communications
    • Network Devices (routers and switches)

    • Internet Protocol (IP) Address



    In-Scope
    In-Scope


    No
    Yes
    Process (Business and IT processes) In-Scope No
    Service
    • Business Service

    • Infrastructure Service



    In-Scope
    In-Scope


    Yes
    Yes
    Software
    • Business Application

    • COTS Applications, O/S, Installed Software, etc.


    Note: Source Codes are not stored in the CMDB.


    In-Scope
    In-Scope


    Yes
    Yes

Authority

  1. This document is sanctioned under IRM 2.150.1 Configuration Management Policy that defines the mandates for the Configuration Management Process.

  2. The Director, Demand Management & Project Governance (DMPG) under Enterprise Operations, is the executive owner for the Configuration Management Program and is responsible for the development, implementation, and maintenance of this process. All proposed changes to this document must be submitted in writing, with supporting rationale, to DMPG.

Roles and Responsibilities

  1. Each process defines at least one role. Each role is assigned to perform specific tasks within the process. The responsibilities of a role are confined to the specific process. They do not imply any functional standing within the hierarchy of an organization. For example, the process manager role does not imply the role is associated with or fulfilled by someone with functional management responsibilities within the organization. Within a specific process, there can be more than one individual associated with a specific role. Additionally, a single individual can assume more than one role within the process although typically not at the same time.

    Process Role Description
    Configuration Management (CM) Process Owner (DMPG) The CM Process Owner is the single point of contact for the process at the enterprise level and is accountable for the overall quality of the process, ensuring that the process is performed as documented and is meeting its objectives. The CM Process Owner’s responsibilities include sponsorship, design, review and continual improvement of the Process and its Metric. Specific responsibilities include–
    • Defines the overall scope, mission, goal, and objectives of the process

    • Ensures consistent execution of the process across the IT organization

    • Ensures that the process, roles, responsibilities and documentation are regularly reviewed and audited

    • Reports on the effectiveness of the process to senior management

    • Accountable for implementation and review of improvement actions

    • Ensures that sufficient resources are in place to support implementation of the process

    • Ensures all relevant staff have the required training in the process and are aware of their role in the process

    • Ensures that the process is in alignment with the process automation tool(s)

    • Resolves any process and cross-functional (departmental) issues

    Configuration Management (CM) Process Manager (IT CM Program) The CM Process Manager supports the CM Process Owner and is responsible for the operational management of the process. The Process Manager’s responsibilities include planning and coordination of all activities required to execute, monitor and report on the process. Specific responsibilities include–
    • Designs, develops, and manages improvements to the process; including plans, principles and its implementation

    • Provides training and communication on the standards, policy, and process to CM stakeholders

    • Plans, facilitates and organizes reviews, assessments, and audits on the process and CMDB with the Configuration Auditor

    • Plans and manages the alignment of the CM tools with the process; including evaluating CM tools and their design, requirements, proposed changes, and implementation

    • Develops, coordinates, and maintains the interfaces to other processes.

    • Defines process metrics for measurement, reporting, and improving the process

    • Escalates any issues with the process

    • Maintains scope of the process, function, and CIs that are to be controlled, and information that is to be recorded

    • Ensures that configuration data is available when and where it is needed to support other IT processes

    • Agrees on the structure of the CMDB, including CI types, naming conventions, required and optional attributes and relationships

    • Designs and generates configuration status reports; including management reports

    Configuration Item (CI) Owner (ITIL/ITSM CM) The CI Owner is accountable for all activities that directly affects their CI(s). This role is also responsible for all ITSM process activities associated with the maintenance and support of the CI. Specific responsibilities include –
    • Ensures that all their CIs are recorded, and the associated attributes and relationship information is accurate

    • Ensures configuration audits are performed on the CMDB

    • Provides input to the CI Librarian/ Analyst into what attributes and relationships need to be tracked within the CMDB

    • Accountable for correcting errors associated with their CIs

    Configuration Item (CI) Librarian/Analyst (ITIL/ITSM CM) The CI Librarian/Analyst supports the CM Process Manager and CI Owner and is responsible for supporting, maintaining, controlling, and updating a specific CI or CIs. Specific responsibilities include –
    • Controls the receipt, identification, storage and withdrawal of all supported CIs, including archives of superseded CIs

    • Identifies and records the CIs in the CMDB, and determining relationships

    • Ensures Data Model is accurate

    • Supports generation of status reports on various CMDB parameters and requests

    • Maintains status information on CIs and provides this as appropriate to stakeholders

    • Assists with conducting configuration audits, performing internal audits and validating exceptions

    • Identifies, records and submits incidents relating to CIs

    • Records and maintains CI Types (within scope) in the CMDB

    • Discovers, reconciles, and updates CI records in the CMDB

    • Validates accuracy of CMDB data and report discrepancies

    • Creates and maintains the service and application models for CIs

    • Provides input to the process scope and procedures.

    Configuration Management System (CMS)/Tools Administrator (ITIL/ITSM CM) The CMS/Tools Administrator supports the CI Librarian/Analyst and is responsible for managing the CMDB which maintains information regarding all the CIs in the organization. Specific responsibilities include –
    • Manages the Configuration Data Model and updates

    • Manages the CM tool functions and changes

    • Manages the CM tool release updates and installation

    • “Gate Keeper” for the CMDB

    • Performs physical management of configuration repositories (CMDB)

    • Interfaces with the tool vendor on issue resolution, knowledge sharing of the tool functionality, new release plans, etc.

    • Ensures the structure of the CMDB, including CI types, naming conventions, required and optional attributes and relationships

    Configuration Auditor (ITIL/ITSM CM) The Configuration Auditor supports the CM Process Manager and is responsible for conducting and/or providing oversight to a configuration audit. Specific responsibilities include –
    • Conducts and/or oversees periodic CMDB audits to check the accuracy, completeness, compliance and security of records against the baseline

    • Conducts reviews and assessments on the CM process to ensure process compliance

    • Consolidates the observations and non-conformances

    • Provides reports to the CM Process Owner, CM Process Manager, and other relevant stakeholders

    • Ensures that reviews are performed by the CI Librarian/ Analyst and CI Owners

    • Validates accuracy of CMDB data and report discrepancies

    • Ensures audit reports are distributed to the CM process stakeholders and CI owners and recommends improvements

    Project Manager (SCM) The Project Manager is responsible for the planning and execution of a project.
    Project Configuration Manager (SCM) The Project Configuration Manager (formerly CM Representative) is assigned and supports the Project Manager and has the following responsibilities:
    • Develops, documents, and implements the project configuration management plan for each information system that:
      • Addresses roles, responsibilities, and configuration management processes and procedures;
      •Defines the CIs for the project
      • Establishes the means for identifying CIs throughout the system development life cycle and a process for managing the configuration of the CIs.

    • Establishes a Configuration Control Board (CCB) when appropriate, and ensures that an approved charter and operating procedures exists for the established CCB

    • Ensures that cost, schedule, risk, and performance aspects of change requests, problem reports, and engineering change proposals are known at the time of their consideration by the respective CCB

    • Participates in configuration audits

    Project Configuration Auditor (SCM) The Project Configuration Auditor supports the Project Manager and Project Configuration Manager and is responsible for conducting and/or providing oversight to the Functional Configuration Audit (FCA) and Physical Configuration Audit (PCA) audits on projects prior to deployment. These configuration audits may be conducted by the software quality assurance or software verification and validation functions.
    Configuration Control Board (SCM) A group of people responsible for evaluating and approving/disapproving proposed changes to CIs, and for ensuring implementation of approved changes.
    Technical Review Board (SCM) A committee that ensures the technology choices made by the organization are the best option for all groups in the organization.
    Scrum Master (SCM) Facilitator for an agile development team.
    Developer (SCM) Responsible for development and maintenance of software applications. This includes:
    • Coordinate identified issues/problems/defects with other testing or project stakeholders or provide a workaround

    • Document all coding

    • Participate in peer reviews of coding and documentation

    • Perform unit testing on the created/changed code

    • Notify project manager of testing status

    • Provide appropriate artifacts to the next phase of testing/deployment

    • Create, update, and maintain appropriate artifacts for testing phases

    Test Analyst (SCM) Responsible for testing, analyzing, compiling data, and generating reports. This includes:
    • Create test related work products (test cases/scripts, test datasets, etc.)

    • Prepare any required reporting documentation for the respective testing activities

    • Execute and document test activities

    • Manage testing requirements, create, duplicate, and execute test cases/scripts, identify and document testing problems, and report testing status

    • Analyze appropriate documentation to extract project requirements

    Test Lead (SCM) Responsible for leading a team of Test Analysts to meet the product goals. This includes:
    • Ensure that all work products are completed (Test Plan, EOTR, etc.)

    • Ensure the verification and acceptance of all test plans and documentation

    • Triage open testing problems, update problem status, and provide solution or workaround for test issues/problems/defects

    • Create, update, and maintain appropriate artifacts for testing phases

    Business Lead (SCM) Responsible for creating, communicating, coordinating, and interpreting the business requirements, including approving various artifacts
    Project Stakeholder (SCM) Members of a project, project managers, executives, project sponsors, customers, and users.

Program Management and Review

  1. The IT CM Program manages the process based on the following guiding principles.

    Name Description
    Process Management
    - Statement

    The Configuration Management process will have a single Process Owner and a separate Process Manager, responsible for implementation and ensuring adherence to the process. The process will be reviewed regularly to ensure that it continues to support the business requirements of the enterprise. Process metrics will be focused on providing relevant information as opposed to merely presenting raw data.
    People
    - Statement







    - Rationale

    Roles and responsibilities for the process must be clearly defined and appropriately staffed with people having the required skills and training. The mission, goals, scope and importance of the process must be clearly and regularly communicated by upper management to the staff and business customers of IT. All IT staff (direct and indirect users of the process) shall be trained at the appropriate level to enable them to support the process.

    It is imperative that people working in, supporting or interacting with the process in any manner understand what they are supposed to do. Without that understanding Configuration Management will not be successful.
    Process
    - Statement














    - Rationale

    Modifications to the Configuration Management process must be approved by the Process Owner. The design of the process must include appropriate interfaces with other processes to facilitate data sharing, escalation and workflow. The process must be capable of providing data to support real-time requirements as well as historical/trending data for overall process improvement initiatives. The process must be fully documented, published and accessible to the various stakeholders of the process. The process will be reviewed on a periodic basis to ensure it continues to support organizational goals and objectives (continuous improvement). The process must include Inputs, Outputs, Controls, Metrics, Activities, Tasks, Roles and Responsibilities, Tool and Data requirements along with documented process flows. The process will be kept straight forward, rational, and easy to understand.

    The process must meet operational and business requirements.
    Technology and Tools
    - Statement
















    - Rationale

    All tools selected must conform to the enterprise architectural standards and direction. Existing in-house tools and technology will be used wherever possible, new tools will only be entertained if they satisfy a business need that cannot be met by current in-house tools. The selection of supporting tools must be process driven and based on the requirements of the business. Selected tools must provide ease of deployment, customization and use. Automated workflow, notification and escalation will be deployed wherever possible to minimize delays, ensure consistency, reduce manual intervention and ensure appropriate parties are made aware of issues requiring their attention. The tools used by this process are the following:
    • IBM Endevor

    • IBM Rational ClearCase

    • IBM Rational Team Concert

    • Micro Focus Universal Configuration Management Database (UCMDB)

    • Micro Focus Universal Discovery

    • Micro Focus UCMDB Browser

    • Micro Focus UCMDB Configuration Manager

    • Micro Focus Service Manager/Change Management Module

    • Micro Focus Work Request Management System

    • UNISYS SQuA

    Technology and tools should be used to augment the process capabilities, not become an end themselves.

Program Control

  1. Program controls are driven by the policies and guiding principles on how the process will operate.

Controls
  1. Controls provide direction on the operation of processes and define constraints or boundaries within which the process must operate.

    Name Description
    CM Policies Policies and mandates for management and control of CIs.
    Change Management Policies Policies and mandates for change control of CIs.
    Scope The scope of the Configuration Management process. Includes identification of what is included in and what is excluded from the Configuration Management process.
    Configuration Audits The frequency of configuration audits to maintain the integrity of the CI and its attributes and relationships.
    Management Reports The frequency and distribution for regularly produced configuration management reports on the status of CIs.
Metrics
  1. Metrics are used for the quantitative and periodic assessment of a process. They should be associated with targets that are set based on specific business objectives. Metrics provide information related to the goals and objectives of a process and are used to take corrective action when desired results are not being achieved and can be used to drive continual improvement of process effectiveness and efficiency.

  2. Management will regularly set targets for process performance, gather quantifiable data related to different functions of the Configuration Management process, and review that data to make informed decisions and take appropriate corrective action, if necessary. All Measurements will have a defined data dictionary, map to the organizational strategic goals, and be documented in a Process Measurement Plan. The Process Measurement Plan template is available in the IT Process Asset Library (IT PAL).

Tailoring Guidelines
  1. The tailoring guidelines identify the allowable variations of the IT organization’s standard process as needed for adjustments (adding, deleting, modifying) relative to specific operational or functional needs of another organization. Process tailoring is about roles and procedures, not the standard process or major activities defined in this process. All tailoring request, with supporting rationale, must be submitted in writing to and approved by the CM Process Owner.

Terms/Definitions/Acronyms

  1. The tables in the Terms/Definitions and Acronyms lists commonly used terms and acronyms in the Configuration Management process.

Terms and Definitions
  1. This table lists commonly used terms in the CM Process.

    Term Definition
    Configuration Audit Audits conducted to confirm that configuration management records and CIs are complete, consistent, and accurate.
    Configuration Item (CI) Type To simplify the management of this massive amount of data CIs and each of the attributes associated with them are organized into classifications called CI Types. CI Types are hierarchical and have attributes that they can inherit from their parents, or that can be instantiated at their level. Their children will then inherit from them.
    Configuration Item (CI) Attributes CIs have “attributes,” characteristics or values that distinguish them. They are like a “field” in a record of a database. Some of these attributes are inherited from a parent CI Type. Many are determined by the specific function of that CI and CI Type. For instance, an attribute of the “Primary IP address” CI Type includes the actual IP address, the subnet mask, the default gateway and information for any additional IP address bound to that network device.
    Configuration Management Database (CMDB) A Configuration Management Database (CMDB) is a database that contains all relevant information about the hardware and software components used in an organization. It includes the components, the IT services they support and the relationships between those components. A CMDB provides an organized view of configuration data and a means of examining that data from different perspectives.
    Functional Configuration Audit (FCA) Audits conducted on baseline components to verify that the development of a CI has been completed satisfactorily, that the item has achieved the functional and quality attribute characteristics specified in the functional or allocated baseline, and that its operational and support documents are complete and satisfactory.
    Infrastructure Service An infrastructure service is a service that is required for IT to deliver the business services but is not directly consumed by the customer; infrastructure services are usually consumed by other applications or services. Services such as backup, directory management (LDAP/AD), and security are common examples of Infrastructure Services.
    Metadata Data that describes other data, or summarizes basic information about data which can make finding and working instances of data easier.
    Model A model is a reusable collection of CI instances that define a business entity, such as a business service or line of business.
    Physical Configuration Audit (PCA) Audits conducted on baseline components to verify that a CI, as built, conforms to the technical documentation that defines and describes it.
    Tier 1 System Supercomputers and Mainframes Supercomputers and mainframe hardware and software, including peripheral subsystems used in a mainframe system environment.
    Tier II System Minicomputers and Servers Minicomputers (i.e. computers usually containing multiple microprocessors, capable of executing multiple processes simultaneously, and may serve multiple users by way of a communications network) including hardware, software, and peripheral subsystems used in that environment. These systems typically include any hardware operating under a multi-user operating system, such as Windows, UNIX, and LINUX. Typically, these systems support centralized, high-volume enterprise applications. Hardware and software maintenance associated with the above items, including performing system backups, hardware upgrades and maintenance, operating systems upgrades and preventive maintenance tasks. Support for providing backups and daily operation of these systems. Windows-based networking servers: Primary Domain Controllers (PDCs), Backup Domain Controllers (BDCs), Windows Internetwork Servers (WINS), file and print servers and their backup systems; Windows-based application servers; and Microsoft Exchange messaging servers
    Tier III System - Microcomputers Tier III - These systems include all workstation devices and any hardware operating under a Windows operating system, including all hardware used in a desktop environment: Workstations functioning with a single-user (stand-alone) operating system including UNIX workstations that run single-user versions of UNIX and workstations that run any Windows operating system. This includes desktops, laptops and docking stations, monitors and keyboards associated with these devices, Personal Digital Assistants (PDAs), scanners, and printers. Tier III also includes new software, hardware and software maintenance associated with the above items, including performing system backups, hardware upgrades and maintenance, operating system upgrades and preventive maintenance tasks.
    Tier IV Data and Voice Telecommunications Data and voice (telecommunications) equipment, including switching equipment (i.e. private branch exchanges (PBXs); package switching equipment, etc., telecommunication networks and related equipment such as voice communications networks, local area networks, data communications networks; automatic call distributor/voice response units (ACDs/VRUs); modems, data encryption devices, fiber optics, terrestrial carrier equipment (multiplexers and concentrators); light wave, microwave, or satellite transmission and receiving equipment, telephonic equipment, and facsimile equipment.
Acronyms
  1. This table lists commonly used acronyms in the Configuration Management process.

    Acronym Description
    ACIO Associate Chief Information Officer
    BSR Business System Report
    CCB Configuration Control Board
    CI Configuration Item
    CM Configuration Management
    CMDB Configuration Management Database
    COH Computer Operations Handbook
    COTS Commercial-Off-The-Shelf
    CPB Computer Program Book
    DMPG Demand Management and Project Governance
    ELC Enterprise Life Cycle
    EOTCR End of Test Completion Report
    FCA Functional Configuration Audit
    FSP Functional Specification Package
    ICD Interface Control Document
    IEEE Institute of Electrical and Electronics Engineers
    IESC Infrastructure Executive Steering Committee
    IRM Internal Revenue Manual
    IRS Internal Revenue Service
    ISO/IEC International Organization for Standardization/International Electrotechnical Commission
    IT Information Technology
    IT PAL IT Process Asset Library
    ITIL Information Technology Infrastructure Library
    ITSM IT Service Management
    PCA Physical Configuration Audit
    PRP Program Requirements Package
    RfC Request for Change
    SCM Software Configuration Management
    SDSR Simplified Design Specification Report
    TRB Technical Review Board
    VSA Vision, Scope, and Architecture

Related Resources

  1. The following lists the primary sources of references used in the development of the CM process.

    • IRM 2.5.1 Systems Development

    • IRM 2.16.1 Enterprise Life Cycle (ELC) Guidance

    • IRM 2.22.1 Unified Work Request (UWR) Process

    • IRM 2.125.1 Change Management Policy

    • IRM 2.125.2 Change Management Process

    • IRM 2.127.1 IT Test Policy

    • IRM 2.127.2 IT Testing Process and Procedures

    • IRM 2.150.1 Configuration Management Policy

    • IEEE Standard for Software Configuration Management in Systems and Software Engineering

    • Software Engineering Body of Knowledge (SWEBOK)

    • ITIL Service Transition 2011: Service Asset and Configuration Management

    • ISO/IEC 20000-1:2018 Information Technology - Service Management (ITSM) - Part 1: Service Management System Requirements

Training

  1. Process training involves training all stakeholders about key processes that are crucial for an organization to deliver business objectives. Training provides clarity to employees on a set of procedures that needs to be carried out as part of the process and the best possible way to do them. Listed below are the training resources available for this process:

    • Configuration Management (CM) Overview, ITM Course #23279

    • Change Management Process Overview, ITM Course #43161

Process Workflow

  1. A process workflow consists of Activities and Tasks, Inputs and Outputs, Roles, and Flow Diagrams. It describes the tasks, procedural steps, organizations or people involved, required input and output information, and tools needed for each step of the process.

Main Process Diagram

  1. The Main Process Diagram illustrates the key process activities and process interfaces for Software Configuration Management (SCM) and ITIL/ITSM Configuration Management processes.

    Figure 2.150.2-2

    This is an Image: 60767003.gif

    Please click here for the text description of the image.

Inputs

  1. Process inputs are used as triggers to initiate the process and to produce the desired outputs. Users, stakeholders or other processes provide inputs. The following is a list of inputs for this process: Process inputs are used as triggers to initiate the process and to produce the desired outputs. Users, stakeholders or other processes provide inputs. The following is a list of inputs for this process:

    Name Description Supplier
    Request for Change (RfC) An RfC (Unified Work Request or Change Request) is the record of a Change proposal for changes to a CI and that is worked through the Unified Work Request or Change Management process. Change Analyst
    Service Request or Request Fulfillment A request for information or fulfillment of an IT service, and is not used for changes to a CI. Users

Outputs

  1. Each process produces tangible outputs. These outputs can take the form of products or data and can be delivered to a user or stakeholder or they can be used as inputs to other processes. Outputs are measurable in terms of quantity and quality.

    Name Description Recipient
    Audit Results Findings from the Functional Configuration Audit (FCA) that is used to verify the actual performance of the CI meets the requirements stated in its performance specification; and for systems, the actual performance of the system meets the requirements stated in the system performance specification. (SCM)

    Findings from the Physical Configuration Audit (PCA) that is used to examine the actual configuration of the CI that is representative of the product configuration to verify that the related design documentation matches the design of the deliverable's CI. This includes validation of many of the supporting processes that are used in the production of the CI as well as any elements of the CI that were redesigned after the completion of the FCA also meet the requirements of the CI's performance specification. (SCM)

    A report summarizing the results of a CMDB audit, highlighting revealed differences between CMDB records and the installed CIs. (ITIL/ITSM CM)
    CM Process Owner, CM Process Manager

    Project Manager, Project Configuration Manager

    CI Owner, CI Librarian/Analyst
    CI Information Information on a CI or multiple CIs. CM Process Manager

    Project Manager, Project Configuration Manager, Project Configuration Auditor

    CI Librarian/Analyst, CI Owner, Configuration Auditor
    CI Structure Chart The CIS Chart is used to define and illustrate system CI relationships. CM Process Manager

    Project Manager, Project Configuration Manager, Project Configuration Auditor
    CM Plan A formal document and plan that describes how configuration management of the IT infrastructure system or component, called CIs, will be managed and controlled throughout its lifecycle. CM Process Manager

    Project Manager, Project Configuration Manager, Project Configuration Auditor
    CM Worksheet A CI register that list all the documentation (configuration baselines) and hardware and software that is required for the project and used to develop, test, deliver, monitor, control, and support Information Technology. This is an optional artifact. CM Process Manager

    Project Manager, Project Configuration Manager, Project Configuration Auditor
    Configuration Baselines A set of specifications or work products that has been formally reviewed and agreed on, that thereafter serves as the basis for further development or delivery, and that can be changed only through change control procedures. (SCM)

    A snapshot of the infrastructure or a part of the infrastructure. (ITIL/ITSM CM)
    CM Process Manager

    Project Manager, Project Configuration Manager

    CI Librarian/Analyst, CI Owner
    Reports Reports on information contained about the status of a CI. For example, historical, baseline information, etc. CM Process Manager

    Project Manager, Project Configuration Manager, Project Configuration Auditor

    CI Librarian/Analyst, CI Owner

Activities

  1. An activity is a major unit of work to be completed in achieving the objectives of the process. A process consists of a sequence of related activities that transforms inputs into outputs and performed by the roles defined in the process. Activities are measurable in terms of efficiency and effectiveness. Identify the activities in the process and provide a brief description. The activities must correspond with the high-level process flow diagram above.

  2. The table below describes the key process activities for Software Configuration Management

    ID Name Description
    SCM 1.0 Management & Planning This activity establishes the Configuration Management Plan that describes the appropriate CM process that will be performed during the product or project lifecycle. It details the CM activities, the assigned roles and responsibilities, the required resources, including staff, tools, and computer facilities.
    SCM 2.0 Configuration Identification This activity identifies software CIs that will be controlled, establishes standard naming convention and schemes, version control, structural relationships between software CIs, CM baselines (functional, allocated, and product), and establishes the tools and techniques for acquiring and managing controlled items.
    SCM 3.0 Configuration Control This activity is responsible for managing changes and release implementation of software changes to CIs and baselined configuration documentation. It leverages on existing formal software change and release processes.
    SCM 4.0 Configuration Status Accounting This activity establishes the process for recording, managing, and reporting on the status of approved configuration documentation, including traceability of all changes.
    SCM 5.0 Configuration Audit This activity establishes the integrity in the configuration documentation used as the basis for configuration control and support of the product throughout the software development lifecycle by maintaining the integrity of the configuration baselines. It confirms that the resulting baselines and documentation conform to the special standards or requirements, and also confirms the integrity of a systems product prior to delivery. There are two types of configuration audits:
    • Functional Configuration Audit (FCA). The objective of the FCA is to provide an independent evaluation of a software product, verifying that its CIs’ actual functionality and performance is consistent with the relevant requirement specification. This audit is held prior to software delivery to verify that all requirements specified in the software requirements and specification have been met.

    • Physical Configuration Audit. The objective of the PCA is to provide an independent evaluation of a software product's CIs to confirm that all components in the as-built version map to their specifications. Specifically, this audit is held to verify that the software and its documentation are internally consistent.

  3. The table below describes the key process activities for ITIL/ITSM Configuration Management.

     
    ID Name Description
    CM 1.0 Configuration Management Planning This activity defines the policies and guidelines for management and control of configuration records for service components and infrastructure items including maintenance of accurate information on the historical, current, and approve future state of services and their infrastructure components.
    CM 2.0 Configuration Identification This activity is responsible for the planning and preparation to identify CIs. This includes the modeling of the infrastructure to determine what CIs will look like and how they are related to each other. It also includes the development of naming conventions, enterprise taxonomy, CI selection and classification, and assignment of CI ownership for defining CI attributes.
    CM 3.0 Configuration Control This activity is responsible for ensuring that only authorized and identifiable CIs are in the infrastructure and that there is a corresponding accurate and complete CI record representing the CI in the CMDB. It ensures that changes to CI records are associated are approved through Change Management.
    CM 4.0 Configuration Status Accounting & Reporting This activity is responsible for producing regular and ad-hoc reports on the current, past and future status of the infrastructure and the CIs in the CMDB.
    CM 5.0 Configuration Verification & Audit This activity is responsible for audit, review and verification on the accuracy of CI records against its actual CI, including relationship information with other CIs to ensure data quality and integrity.

Procedure for Configuration Management under Software Development (SCM)

  1. This procedure is specific for the application of Configuration Management under software engineering for development and management of software CIs under the software development process.

SCM 1.0: Management & Planning
  1. This activity establishes the planning of SCM process for a given project.

    ID Task Name and Description Role RACI Duties
    SCM 1.1 Organization and Responsibilities.

    The purpose of this task is to define individual roles and responsibilities, including organizational entities.
    Project Configuration Manager

    Project Manager
    R



    I
    Identify CM participants and organizational entities involved in the product/project development and ensure that all CM participants receive training or request for training using the service catalog in the CM Front Door SharePoint site.

    Note:

    The Project Configuration Manager had already been identified and assigned by the Project Manager to execute the CM process for the project.

    SCM 1.2 Resources and Schedule

    The purpose of this task is to identify staff and tools involved in carrying out CM activities.
    Project Configuration Manager

    Project Manager
    R



    I
    Identify staff and tools involved in carrying out CM activities and tasks. This includes scheduling by establishing necessary sequences of CM tasks in delivering required CM artifacts based on the project schedule, ELC tailoring plan, and ELC milestones. Any training requirements necessary for implementing the plans and training new staff members are also specified.
    SCM 1.3 Tool Selection and Implementation

    The purpose of this task is to develops plans for tool selection and implementation.
    Project Configuration Manager

    Project Manager
    R



    I
    Tool selection and implementation must be carefully planned to ensure that it can support both current and future use by the project. The following are some considerations that need to be made:
    • commercial or in-house tools

    • operating environment

    • how projects will use the tools

    • financing, acquisition, maintenance, and training

    • scope of implementation - entire organization or specific to the project

    • ownership and technical support group

    • adaptability to change and customization

    • integration with other tools in the organization

    • future use and upgrades

    SCM 1.4 Vendor/Subcontrator Control

    The purpose of this task is to develop plans for management of vendor/subcontractor tools to enforce CM requirements.
    Project Configuration Manager

    Project Manager
    R



    I
    Software projects that acquire or make use of commercial tools, CM planning must be considered how these items will be under configuration control and how changes or updates will be evaluated and managed. This includes subcontracted software to ensure that CM requirements are imposed on the subcontractor’s CM process as part of the subcontract and the means for monitoring compliance need to be established by identifying what CM information must be available to effectively monitor for compliance.

    Note:

    These projects are usually under Managed Services or Commercial-Off-The-Shelf (COTS) ELC Paths.

    CM 1.5 CM Process

    The purpose of this task is to define the appropriate CM process right-sized for the project.
    Project Configuration Manager

    Project Manager
    R



    I
    There are various types of software development or software solution methods such as Agile, Common Services, COTS, Managed Services, and Waterfall models. An appropriate CM process (based on the four functions, i.e., Configuration Identification, Configuration Control, Configuration Status Accounting, and Configuration Audit) must be planned, tailored or defined based on the type of model with respect to the size and scope of the project. This includes the application of the appropriate tools that facilitate the process and management of the software CIs.
    SCM 1.6 Develop CM Plan or Addendum

    The purpose of this task is to develop a CM Plan or Addendum to record the CM planning activities.
    Project Configuration Manager

    Project Manager
    R



    I
    The result of the CM planning is recorded in a Configuration Management Plan or Addendum to the ACIO CM Plan. A CM Plan or Addendum is a required ELC deliverable in the Planning Phase.

    Determine if a Project CM Plan or Addendum will be created. The ACIO CM Plan Owner must be contacted to evaluate whether the Project can leverage or document the deviations on the Addendum. The Project may still opt to develop a CM Plan at discretion but must inform the ACIO CM Plan Owner of the decision.

    A deviation from the ACIO CM Plan is determined if any of the following are different:
    • Roles and responsibilities

    • Change authority

    • Standard Tools

    • Procedure


    Obtain and complete the appropriate template, CM Plan or Addendum, from the IT PAL, and submit to the CM Front Door for review and approvals for the ELC Milestone 1/2 Readiness Review or Product Planning Review (Agile).

    Note:

    An ACIO CM Plan has been established by each Associate Chief Information Officer (ACIO) that defines the CM standards and best practices that each ACIO organization will follow to manage and control their CI assets. Projects may leverage from ACIO CM Plan, or at discretion create a Project CM Plan. If there is a Program CM Plan, a Project CM Plan is required to be created, and it cannot leverage from an ACIO CM Plan. This is because the ACIO CM Plan is an agreement between the IT CM Process Owner and each ACIO to establish CM organization standards, and not at the program-level.

  2. RACI is a responsibility matrix that describes the participation by various roles in completing the tasks or deliverables for a project or business process. RACI is derived from the four key responsibilities typically used:

    • Responsible – The person that is assigned to do the work.

    • Accountable – The person that makes the final decision and has ultimate ownership.

    • Consulted – The person that must be consulted before a decision or action is taken.

    • Informed – The person that must be informed that a decision or action has been taken.

SCM Management & Planning Cross-Functional Flow Diagram
  1. The following figure illustrates the Management & Planning workflow.

    Figure 2.150.2-3

    This is an Image: 60767004.gif

    Please click here for the text description of the image.

SCM 2.0: Configuration Identification
  1. This activity identifies software CIs to be controlled including identification schemes and tools for managing controlled items.

    ID Task Name and Description Role RACI Duties
    SCM 2.1 Select Software Configuration Items

    The purpose of this task is to identify and select software CIs.
    Project Configuration Manager R Identify software items that need to be managed and controlled. This involves understanding the software configuration within the context of system configuration and selecting software CIs.

    Software configuration is the functional and physical characteristics of the hardware/software defined in the technical documentation resulting in the final product--which makes up the overall system configuration. The following are software CIs:
    • plans

    • specifications and design documents

    • testing materials

    • software tools

    • source and executable codes

    • code libraries

    • data and data dictionaries

    • documentation for installation, maintenance, operations and software use

    SCM 2.2 Assign Configuration Identification Index (CII)

    The purpose of this task is to assign unique identification labels for each software CI.
    Project Configuration Manager

    CM Process Manager
    R



    C
    Software CIs identified must be assigned unique identifiers, called Configuration Identification Index, which are unique identification labels as part of controlling and managing changes to software CIs. A standard CII structure and naming convention has been established in the CM Worksheet Instructions located in the IT PAL. An optional CM Worksheet template is also available for recording software CIs and its attributes.

    Note:

    For hardware CIs, such as servers, its configuration records are registered separately in the IT automated CMDB. Source codes are also maintained separately in other CM tools.

    SCM 2.3 Identify Relationships

    The purpose of this task is to identify relationships to create the models.
    Project Configuration Manager

    CM Process Manager
    R



    C
    Identifying relationships between software and hardware is a required activity in order to determine the impact of a change or incident against other CIs. This enables identification of interfaces between applications and infrastructure.

    The results of identifying relationships are recorded in a Configuration Item Structure (CIS) Chart. A CIS Chart is a required ELC deliverable in the Design Phase or System Development Phase (Agile).

    Obtain and complete the CI Structure (CIS) Chart template from the IT PAL and submit to the CM Front Door for review and approvals for the ELC Milestone 3/4a Readiness Review or Integrated Readiness Review (Agile).

    Note:

    For hardware CIs, such as servers, relationships are automatically identified based on dependencies between CIs stored in the CMDB.

    SCM 2.4 Establish Baselines

    The purpose of this task is to establish software baselines as the CI progresses through the software development lifecycle.
    Project Configuration Manager R Software baseline is a formally approved version of software CIs that is formally agreed upon and establishes the basis for a formal change process for future changes to software CIs. Baselines must be established as the software CI progresses through the software development lifecycle.

    Functional baseline defines the functionality requirements of the system or system specifications (system level architecture and design) and its interface characteristics containing the system’s capability, functionality, and overall performance. It is established upon completion of system requirements review under the Domain Architecture Phase. This consist of approved configuration documentation describing a system or top level CI’s performance, such as the Business System Report (BSR) and Vision, Scope and Architecture (VSA) for Agile projects.

    Allocated baseline defines the configurations items that compose the system and how it is distributed or allocated across lower-level CIs. It is established upon completion of software requirements and software interface requirements review under the Logical and Physical Design Phase. This consist of approved configuration documentation describing the functional and interface characteristics allocated from the system for each CI, such as Functional Specification Package (FSP), Program Requirements Package (PRP), or Simplified Design Specification Report (SDSR).

    Product baseline defines the release contents (CIs) of the project for production. It is established upon completion of all technical documentation and software for product testing and acceptance that culminates in the FCA/PCA under the Systems Development Phase. This consist of the source code and approved technical documentation describing the configuration of a CI for production and operational support, such as Computer Operator Handbook (COH), Computer Program Handbook (CPB).

    Note:

    For software that is acquired, its origin and initial integrity must be established. Following the acquisition of a software, changes to the item must be formally approved and baseline according to the appropriate procedure.

    SCM 2.5 Establish Software Libraries Project Configuration Manager R A software library is a controlled collection of software and related documentation for software development. It is also use for software release management and deployment activities.

    Software libraries must be established for source code management and control, development, and testing. Tools used to support the software libraries must support CM controls such as version and access control.

    Software libraries must also be established for CI related documentation to maintain current baselines and previous versions. These should include plans, designs, requirements, and any technical and operational documentation that support the software.
SCM Configuration Identification Cross-Functional Flow Diagram
  1. The following figure illustrates the Configuration Identification workflow.

    Figure 2.150.2-4

    This is an Image: 60767005.gif

    Please click here for the text description of the image.

SCM 3.0: Configuration Control
  1. This activity defines the process for managing changes to software CIs using the Change Management process in the software development lifecycle.

    ID Task Name and Description Role RACI Duties
    NA Change Management Change Initiator/Requestor

    Change Coordinator

    Change Manager

    Change Approver

    Business Lead
    NA Change Management defines the process for managing changes to the software application. The first step for managing changes to CIs is determining what changes to make. Once it has been determined, a change pre-coordination meeting with the appropriate developers and other IT suppliers are conducted by the requestor on the desired changes. The next step flows into the formal change procedures for submitting and recording the change request, evaluating potential impact and cost of the proposed change, and accepting, modifying, deferring, or rejecting the proposed changed. The authority for making decisions on the proposed changes is under the Configuration Control Board (CCB). For smaller projects, the authority is delegated to a tier-level change authority based on specific criteria defined for its scope and control.

    Note:

    Formal change procedures are documented in IRM 2.22.1 and IRM 2.125.2. Change procedures for agile is not addressed in this context.

    SCM 3.1 Review and Disposition Change Proposals

    The purpose of this task is to evaluate and disposition (approve/disapprove) change proposals.
    CCB

    TRB

    Project Configuration Manager
    R

    C

    I
    Change proposals are reviewed for impact of a change against other CIs. A change package is normally submitted to the CCB for review and disposition of change proposals.

    Note:

    Change articles may be work request and/or change request. Changes to controlled CIs must use a formal change process. A Change Package is created resulting from the review and assessment by the technical teams such as a Technical Review Board (TRB) where applicable.

    D 3.1 Is the change approved? CCB

    TRB

    Project Configuration Manager
    R

    I

    I
    Determine and disposition the change proposal:
    • If change proposal is approved, go to Implement Software Changes.

    • If change proposal is not approved, the change request is returned and the process ends.

    Note:

    Once the change proposal is approved, the change is implemented through software development and testing processes. When the change is accepted from testing, the configuration records are revised in the software libraries establishing a new baseline and stakeholders are notified of the change.

    SCM 3.2 Implement Software Changes Change Analyst

    Developer

    Test Analyst
    R

    I

    I
    Approved change requests are implemented using defined software procedures based on type of software development lifecycle. Additionally, since there are a number of approved change requests that might be implemented simultaneously, it is critical to track which change request are incorporated for each software versions and baselines. As part of the change process closure, completed changes may undergo configuration audits and software quality verifications to ensure that only approved changes have been made.
    NA Software Development Developer

    Business Lead

    Project Manager
    NA Approved change requests are received by Developers for review and analyses of the requirements resulting in design, development and testing of the software product based on the defined requirements. Upon completion of unit testing and peer review, the software is released for software quality assurance testing.

    Formal software development procedures are defined in IRM 2.5.1.
    NA Software Testing Test Analyst

    Developer

    Project Manager

    Business Lead
    NA Approved change requests are also received by software quality assurance to plan, prepare, and implement test activities, such as developing test plans, test cases and test scripts and documenting and reporting on the test results to Developers for correcting software defects.

    Individual software applications are integrated with other software products for the final system integration testing. Successful completion of integration testing prepares the software for software release management.

    Formal testing procedures are defined in IRM 2.127.2.
    NA Software Release Management Release Manager

    Developer

    Project Manager
    NA Software release management is the identification, packaging, and delivery of all software CIs, such as executable program, documentation (e.g., Version Description Documentation or VDD), release notes, and configuration data. This includes delivery of the installation instructions and other data concerning the use of the new system, and defining the environment on which the software will run.
SCM Configuration Control Cross-Functional Flow Diagram
  1. The following figure illustrates the Configuration Control workflow.

    Figure 2.150.2-5

    This is an Image: 60767006.gif

    Please click here for the text description of the image.

SCM 4.0: Configuration Status Accounting
  1. This activity is concerned about identifying what information is needed for various activities, obtaining the information, and reporting on it as the software CI progresses through the software development lifecycle.

    ID Task Name and Description Role RACI Duties
    SCM 4.1 Identify and Record Software Configuration Status Information

    The purpose of this task is to identify, collect, and maintain software configuration status for reporting.
    Project Configuration Manager

    Project Manager
    R



    I
    Identify, record, and maintain software configuration status information for software CIs that were approved and baselined and its activities for management, software engineering, and other related needs. This includes establishing measurements and tracking change request status, deviations, and waivers as it progresses through the software development process. For example:
    • Record all approved configuration documentation with CIIs associated for each

    • Record and report the status of all change requests associated with each CI

    • Record and report the status of configuration audits (formal or informal) against the status of corrective actions

     

    Note:

    Some of these may already have been recorded in the optional CM Worksheet, if completed at discretion. These include but not limited to: (1) items that are used as input to conduct formal reviews, milestone reviews and decision point reviews such as the System Requirements Review, Milestone Exit Review, Test Readiness Review, etc.; (2) items associated with the project to satisfy contracts, accomplish assignments or provide information to the project; (3) items that will be delivered to the field or organizations outside of the project or key management personnel, groups, or organizations associated with the project; and (4) items that will be used for application, execution, implementation, or sustainment

    SCM 4.2 Report on Software Configuration Status

    The purpose of this task is to identify the types of reports, frequency, and audience to report on the configuration status.
    Project Configuration Manager

    Project Manager
    R



    C
    Identify the type of report(s) (formal or informal), frequency of reporting, and the audience to report on the configuration status information. For example:
    • What kind of report to produce for each selected software CI

    • What is the frequency for reporting on the status for each selected software CI

    • Who are the stakeholders that will receive the reports


    Report on the configuration status and distribute the reports to identified stakeholders.

    Note:

    Distribute the reports to the stakeholders. Archive the reports to provide an audit trail. Examples of information typically presented in the reports include, but are not limited to the following items: (1) change request status; (2) deficiency or defect report status; (3) action item status; (4) change implementation status; (5) system and subsystem versions; (6) document status (i.e., requirements documents, design documents, test documents, plans, etc.); (7) release composition (versions of system files and documents that are contained in a particular release); and (8) test status.

SCM Configuration Status Accounting & Reporting Cross-Functional Flow Diagram
  1. The following figure illustrates the Configuration Status Accounting & Reporting workflow.

    Figure 2.150.2-6

    This is an Image: 60767007.gif

    Please click here for the text description of the image.

SCM 5.0: Configuration Audit
  1. Software configuration audits determines whether the software product matches the capabilities defined in the specifications or contractual documentation and that the performance fulfills the requirements of the user or customer. It increases software visibility and establishes traceability of changes throughout the development lifecycle. In addition, it reveals whether the project requirements are being satisfied and whether the preceding baseline has been fulfilled. The audits enable project management to evaluate the integrity of the software product being developed, resolve issues that may have been raised by the audit, and correct defects in the development process. Software configuration audits are conducted prior to software deployment to ensure that the software product has been built and tested according to specified requirements and all items that are designated as part of the configuration are installed as defined by its requirements.

  2. There are two types of audits that must be performed prior to release of a product baseline or a revision of an existing baseline, Functional Configuration Audit (FCA) and Physical Configuration Audit (PCA). An FCA ensures that each item of the software product has been tested to determine that it satisfies the functions defined in the specifications. A PCA determines whether all items identified as being part of the configuration are present in the product baseline. The FCA/PCA are formal audit processes in most software development lifecycle methodologies, such as Waterfall and COTS. However, for Agile, software configuration audits are informal and iterative. The following sections below describes the standard approach for FCA, PCA, and Agile configuration audits.

SCM 5.1: Configuration Audit - Functional Configuration Audit (FCA)
  1. The FCA is a Software Configuration Management (SCM) activity and ensures that the functional and performance attributes of a CI (baseline components) are achieved (done right thing). In other words, the CIs are doing the right thing. The FCA should occur at least once for new development but may be held more frequently as determined by the project manager.

    ID Task Name and Description Role RACI Duties
    SCM
    5.1.1
    Plan FCA Audit

    The purpose of this task is to plan the audit and identify the resources, i.e., Project Configuration Manager, Project Configuration Auditor, Test Manager, customer representative, etc. that will be involved in the audit.
    Project Manager

    Project Configuration Manager

    Project Configuration Auditor

    Business Lead
    R


    I



    I



    I
    Plan the audit.

    Identify and notify the resources that will support the audit.

    Note:

    Pre-requisites to commence the audit: (1) the development of a CI has been completed satisfactorily; (2) the item has achieved the performance and functional characteristics specified; (3) its operational and support documents are complete and satisfactory; and (4) after completion of the Test Execution Phase—i.e., test phase after completion of the Test Readiness Review.

    SCM
    5.1.2
    Gather FCA Audit Review Materials

    The purpose of this task is to identify and gather review materials
    Project Configuration Manager R Gather all applicable material for review. Use the optional CM Worksheet, if completed, for registered functional and allocated configuration baseline work products.

    Prepare audit checklist using the FCA Checklist.
    SCM
    5.1.3
    Support FCA Audit

    The purpose of this task is support the FCA audit by coordinating the audit activities, reviewing the status, and consolidating audit results.
    Project Configuration Manager

    Project Manager
    R



    C
    Ensure Project Configuration Auditor is aware of their responsibilities.

    Coordinate the FCA activities on the formal audit agenda.

    Gather all audit interim and finalized checklist at the end of the day for audits that cover more than one day.

    Review audit status with the Project Configuration Auditor at the end and beginning of each day when audit covers more than one day.

    Consolidate audit results upon completion of the audit.

    Ensure the accomplishment of the FCA
    SCM
    5.1.4
    Conduct FCA Audit
    The purpose of this task is to conduct the FCA audit.
    Project Configuration Auditor

    Test Analyst

    Test Lead

    Developer

    Project Manager

    Business Lead

    Project Configuration Manager
    R



    I

    I

    I

    I


    I


    I
    Perform the following tasks for the FCA audit:
    • Review test procedures and results against test specifications and procedures.

    • Review analysis or simulations when specific parameters are not verifiable during CI testing.

    • Review internal documents to verify that there are records of the physical configuration or the version of the CI for the recorded test data.

    • Ensure corrective actions have been taken for cases that failed during testing.

    • Conduct tests and retests to assure quality of the product.

    • Obtain a briefing on each CI and discuss the following with the producer: requirements not met, solutions deficiencies, engineering change proposals incorporated and those not tested, and CI testing in general to include problems and successes.

    • Audit the Test Plan, test scripts, and EOTCR for each CI and check for completeness and accuracy. Ensure the correction and documentation of all discrepancies.

    • Audit system evaluation documents validating test accuracy and completeness.

    • Review all approved engineering change proposals ensuring their technical incorporation and verification.

    • Review all operational and support manuals ensuring they are accurate and consistent.

    • Review all past formal review meeting minutes and verify the completion of required corrective actions.

    • Review and validate CI interface requirements and testing.

    • Review database requirements, storage allocations, data and timing, and sequencing characteristics for compliance with specified and design requirements.

    • Compile and sign the FCA checklist.

    Note:

    The following inputs are required: (1) functional requirements document such as the software requirements specification or general requirements specification; (2) system design documents such ICD, design document, database specifications, etc; (3) test plan; (4) test scripts; (5) End of Test Completion Report (EOTCR); and (5) other input as specified by the functional requirements and planning documents

    SCM 5.1.5 Document and Report FCA Audit Findings

    The purpose of this task is to ensure that all tasks are completed during the audit and all findings are documented, using the FCA Checklist.
    Project Configuration Auditor

    Test Analyst

    Test Lead

    Developer

    Project Manager

    Business Lead

    Project Configuration Manager
    R



    I

    I

    I

    C


    I


    I
    Review FCA Checklist to ensure all tasks are completed and findings are documented.

    Compile and sign the FCA Checklist and supporting materials.

    Obtain signature from the Project Manager for closure.

    Note:

    The FCA Checklist and any supporting materials used to document the audit results must be placed under configuration control and made available to the Project Configuration Manager.

SCM Configuration Audit - FCA Cross-Functional Flow Diagram
  1. The following figure illustrates the Configuration Audit - FCA workflow.

    Figure 2.150.2-7

    This is an Image: 60767009.gif

    Please click here for the text description of the image.

SCM CM 5.2: Configuration Audit –Physical Configuration Audit
  1. The PCA is a Software Configuration Management activity and ensures that the CI (baseline components) is installed as defined by the requirements in its detailed design documentation (done thing right). In other words, that you have the right CIs in place. A PCA should be accomplished on the product baseline for each release to verify its authenticity before the full deployment decision to verify compliance with the stated requirements and to ensure that all life-cycle documentation supports the added functionality.

    ID Task Name and Description Role RACI Duties
    SCM
    5.2.1
    Plan PCA Audit

    The purpose of this task is to plan the audit and identify the resources, i.e., Project Configuration Manager, Project Configuration Auditor, Test Manager, and customer representative, etc. that will be involved in the audit.
    Project Manager

    Project Configuration Manager

    Project Configuration Auditor

    Business Lead
    R


    I



    I



    I
    Plan the audit

    Identify and notify the resources that will support the audit.

    Note:

    Pre-requisites to commence the audit: (1) work products in the product baseline and (2) project configuration management plan.

    SCM
    5.2.2
    Gather PCA Audit Review Materials
    The purpose of this task is to identify and gather review materials.
    Project Configuration Manager R Gather all applicable material for review. Use the optional CM Worksheet, if completed, for registered functional, allocated, and product configuration baseline work products.

    Prepare audit checklist using the PCA Checklist.
    SCM
    5.2.3
    Support PCA Audit

    The purpose of this task is support the PCA audit by coordinating the audit activities, reviewing the status, and consolidating audit results.
    Project Configuration Manager R Ensure Project Configuration Auditor is aware of their responsibilities.
    Coordinate the PCA activities on the formal audit agenda.

    Gather all audit interim and finalized checklist at the end of the day for audits that cover more than one day.

    Review audit status with the Project Configuration Auditor at the end and beginning of each day when audit covers more than one day.

    Consolidate audit results upon completion of the audit.
    SCM
    5.2.4
    Conduct PCA Audit

    The purpose of this task is to conduct the PCA audit.
    Project Configuration Auditor

    Test Analyst

    Test Lead

    Developer

    Project Manager

    Business Lead

    Project Configuration Manager
    R



    I

    I

    I

    I


    I


    I
    Each CI must be audited and must perform the following tasks:
    • Review differences between CI being audited and its configuration management records in the PCA Checklist as comments.

    • Review test plans, test scripts, and test reports as well as product specifications to ensure the product complies with its design requirements

    • Ensure the correction of discrepancies noted during the FCA on each CI

    • Ensure all CI design descriptions are defined consistently

    • Ensure all applicable system documentation is complete

    • Certify each CI accepted complies with the specifications and is included in the release package

    • Compile the PCA Checklist.

    Note:

    The following inputs are required: (1) list of approved changes to CI; (2) test scripts; (3) test reports; (4) test results of all test performed; (5) manuals, such as Computer Operator’s Handbook (COH); (6) FCA Audit results; (7) all open Action Items from previous reviews; and (8) any other documentation required by the Project Configuration Manager.

    SCM 5.2.5 Document and Report PCA Audit Findings

    The purpose of this task is to ensure that all tasks are completed during the audit and all findings are documented, using the PCA Checklist.
    Project Configuration Auditor

    Test Analyst

    Test Lead

    Developer

    Project Manager

    Business Lead

    Project Configuration Manager
    R



    I

    I

    I

    C


    I


    I
    Review PCA Checklist to ensure all tasks are completed and findings are documented.

    Compile and sign the PCA Checklist and supporting materials.

    Obtain signature from the Project Manager for closure. Software ready for Deployment Decision.

    Note:

    The PCA Checklist and any supporting materials used to document the audit results must be placed under configuration control and made available to the Project Configuration Auditor.

SCM Configuration Audit - PCA Cross-Functional Flow Diagram
  1. The following figure illustrates the Configuration Audit - PCA workflow.

    Figure 2.150.2-8

    This is an Image: 60767010.gif

    Please click here for the text description of the image.

SCM CM 5.3: Configuration Audit –Agile Audit
  1. The Agile Audit is a Software Configuration Management activity that supports Agile development and unlike the traditional method (FCA/PCA), the approach is flexible, iterative, and focuses on continuous communication and collaboration between the audit team and stakeholders, and is completed in shorter time frames.

    ID Task Name and Description Role RACI Duties
    SCM
    5.3.1
    Create Backlog

    The purpose of this task is to create an audit backlog that defines the scope items for the audit.

    Note:

    Scope items are user stories. User stories are short descriptions of a feature from and end-user perspective.

    Project Configuration Auditor

    Project Stakeholders

    R


    C
    Create audit backlog.
    • Identify and list all scope items

    • Review and prioritize based on risk and value

    • Update based on the needs of the organization, such as emerging issues experienced by stakeholders

    • Collaborate with stakeholders on how an item in the backlog will be tested, examined, or reviewed; expected value from the test; and audit requirements

    SCM
    5.2.2
    Initiate Sprints
    The purpose of this task is to complete the audit within sprint intervals.

    Note:

    Sprints are time-based intervals where audit work is conducted.

    .
    Project Configuration Auditor R Establish and initiate sprints
    • Divide audit into small increments

    • Group user stories into sprints which usually last 1 to 2-weeks

    • Conduct audit

    SCM
    5.2.3
    Close Sprints

    The purpose of this task is close out each sprint through Sprint Meetings.
    Scrum Master

    Project Configuration Auditor

    Project Stakeholders
    R


    C



    I
    Conduct Sprint Meetings at end of each sprint
    • Review backlog items that were completed

    • Demonstrate completed work to obtain concurrence

    • Develop Point of View (POV) summary for each sprint

     

    Note:

    A POV report summarizes all relevant insights gained from observations and stories.

SCM Configuration Audit - Agile Audit Cross-Functional Flow Diagram
  1. The following figure illustrates the Configuration Audit - Agile Audit workflow.

    Figure 2.150.2-9

    This is an Image: 60767017.gif

    Please click here for the text description of the image.

Procedure for Configuration Management under IT Service Management ((ITSM)

  1. This procedure is specific to the application of Configuration Management under IT Service Management for infrastructure CIs and management of its configuration records in the Configuration Management Database (CMDB).

CM 1.0: Configuration Management Planning (ITSM)
  1. This activity establishes the principle requirements and policies and design of the CMDB.

    ID Task Name and Description Role RACI Duties
    CM 1.1 Identify Stakeholders

    The purpose of this task is to identify key CM stakeholders that will define the CM policies to reflect enterprise goals and objectives.
    CM Process Manager R Identify key CM stakeholders that understands business needs and have knowledge of technical aspects of managing the configurations of the IT infrastructure.

    Communicate mission, goals, and objectives of the process.

    Note:

    The stakeholders are the bridge between the Business and IT. They are to be included in policy activities and are also links between all the processes.

    CM 1.2 Conduct Requirements Sessions

    The purpose of this task is to ensure that a mechanism exists by which new requirements may be submitted for consideration and available to all applicable stakeholders.
    CM Process Manager R Establish schedule to meet on regular basis to conduct review of the process effectiveness, efficiency, policies, guiding principles, and to gather requirements for process improvement. Ad Hoc sessions could be called to address issues and/or new requirements.

    Gather, evaluate, and disposition all requirements and forwarded based to each specific tasks:
    • Guiding Principle

    • Policies

    • Configuration Management Development

    CM 1.3 Review Guiding Principles

    The purpose of this task is to identify Guiding Principles to ensure that subsequent policy changes do not stray from the spirit of what was intended.
    CM Process Manager R Coordinate development and revision of Guiding Principles to align with business requirements.

    Ensure that guiding principles are clear as possible.

    Distribute to all stakeholders for review prior to policy review sessions.

    Note:

    Guiding Principles are a precursor to establishing or revising process policies and a set of guiding principles should be identified. Examples of guiding principles are (1) automate where automation is possible; (2) provide traceability within the enterprise; (3) develop a strategy for how new hardware will be provisioned and configured; (4) managed hardware configurations effectively and with strategy; develop mechanism that will provide self-service model for deploying infrastructure changes; and (6) educate the organization on CM practices.

    CM 1.4 Review Configuration Policies

    The purpose of this task is to define and update the configuration policy.
    CM Process Manager R Coordinate the formulation or revision of configuration policy including special emphasis on the CIs for which the role is responsible. Policies will be also be documented and updated in IRM 2.150.1.

    Note:

    Configuration policies are intended to provide direction and guidance for all stakeholders and participants in the process, or for those involved in activities that may interact with the CM process. Policies may be very specific or may focus more on direction or strategy, and be enforceable. They should NOT be tied to dynamic variables such as release levels or specific products, and should stand the test of time. Policies should be easy to understand by all parties to which they apply and should be documented and published to all applicable stakeholders.

    CM 1.5 Configuration Management Design

    The purpose of this task is to produce a design and specification for all aspects of the CMDB.
    CM Process Manager

    CMS/Tools Administrator
    R


    C
    Design and/or facilitate design effort with CMS/Tools Administrator. This includes the CMDB Architecture and its interfaces and security that includes the design of authorizations, roles and access for all of the tools, data, and components.

    The design includes review of various CM tools that will contain requirements for individual technology domains for tasks such as discovery, reconciliation, detection, and reporting of configuration changes and report.
    CM 1.6 Establish Configuration Management Plan

    The purpose of this task is to establish the CM Plan.
    CM Process Manager

    CM Process Owner

    CMS/Tools Administrator/CI Librarian/Analyst
    R


    A


    I
    The result of the planning establishes the CM Plan containing the guiding principles, policies, scope and objective, roles and responsibilities, design of the CMDB architecture and its interfaces, and the appropriate CM process that will be used to manage and control the CI records in the CMDB.

    CM Process Owner approves and publish new/revised CM Plan.

    Note:

    Changes to the CM Plan will require CM Process Owner approval prior to publication.

Configuration Management Planning (ITSM) Cross-Functional Flow Diagram
  1. The following figure illustrates the Configuration Management Planning workflow.

    Figure 2.150.2-10

    This is an Image: 60767013.gif

    Please click here for the text description of the image.

CM 2.0: Configuration Identification (ITSM)
  1. This activity establishes standards and requirements for defining and modeling CIs.

    ID Task Name and Description Role RACI Duties
    CM 2.1 Build Logical Model

    The purpose of this task is to define standard ways for modeling CIs and their relationships.
    CM Process Manager

    CI Librarian/Analyst
    R


    C
    Infrastructure components must have a representation in the models and standard methods for modeling CIs and their relationships must be defined and applied consistently across the IT organization. Standard methods for modeling services, applications, and components must be established and then creating conceptual logical model of the infrastructure. These standard methods and conceptual models will become requirements for modeling the services, application, and infrastructure in the CMDB.

    The logical model defines the scope of the CM activities, that is the level of detail that the organization would want to trace the relationships. Initially beginning with a high-level approach by defining several key services and tracing them back to the application to servers and other service components.
    CM 2.2 Establish Enterprise Taxonomy and CI Naming Convention

    The purpose of this task is to establish common terms and definitions.
    CM Process Manager

    CI Librarian/Analyst
    R


    C
    Services and applications can be referred to by multiple names. Standardization of terms for service and application components is required to consistently model the service and all of its related components in the CMDB. Standard terms and definitions must be defined and publish. Accordingly, using the logical model, define what parts of an application will be designated as a service, what parts will be designated as an application, and what are the parts that are running on the server.

    A standard naming convention must be establish to assign unique identification of infrastructure components in the CMDB. This requirement will create a standard naming convention that can be applied across the IT organization which will allow automatic generation of names. Naming convention standards for naming infrastructure component items must be in place in order to do modeling.

    Note:

    Exception is if standard naming convention is defined in the application and automatically generated.

    CM 2.3 Define CI Types

    The purpose of this task is to identify CI types and establish guidelines for selection of CI and CI types.
    CM Process Manager

    CI Librarian/Analyst
    R


    C
    Define CI types based on the logical model. This entails categorizing any and all CIs that will be managed (e.g., services, applications, servers, database, etc.). This will also establish guidelines for the selection of CIs and define a set of CI types.

    The selection of CIs and the level to which they are defined are very important parameters in the design of the CMDB. That is, if the level is defined too granularly, the CMDB can become cumbersome, bloated and difficult to manage. If the level is too high, the CMDB may not meet the operational requirements of the supported processes.
    CM 2.4 Assign CI Owner

    The purpose of this task is to identify and assign CI Owner for each CI type.
    CM Process Manager

    CI Owner

    CI Librarian/Analyst
    R


    C

    I
    Identify and assign an owner for each CI type. The CI Owner will be responsible for identifying the information about the CI type, such as what attributes are needed and valid values and/or parameters for each attribute, and the source for gathering the information.
    CM 2.5 Define CI Attributes

    The purpose of this task is to define the attributes for each CI type.
    CI Owner

    CM Process Manager

    CI Librarian/Analyst
    R

    I


    I
    Define and select the attributes for each CI type that is owned. An attribute is a piece of information about the CI such as name, location, version number, etc. This includes any valid values and/or parameters for each attribute.
    CM 2.6 Identify Sources of Information for CI

    The purpose of this task is to identify the sources of information for the CI.
    CI Owner

    CM Process Manager

    CI Librarian/Analyst
    R

    C


    C
    Identify the sources where the information can be found for each CI. For example, an auto discovery tool could be used to identify and gather the information and related components on the network. This includes other CMS tools, such as from Asset Management database.
    CM 2.7 Map Relationships between CIs

    The purpose of this task is to build the relationships between CIs.
    CI Librarian/Analyst

    CI Owner

    CM Process Manager
    R


    C

    I
    Conduct mapping of relationships between CI components. Relationships, and the ability to map those relationships to CIs, are the defining characteristic of configuration management. Relationships are what convert an inventory of the infrastructure in the CMDB that can be used for creating service maps, determining impact, analyzing the risk of a change, and building a model of the infrastructure.

    This exercise is taking the logical model created in the first step and overlaying it with the actual hardware, software, and infrastructure components that exist in the IT environment.

    Note:

    This step may be performed by an automated tool or may be performed manually.

    CM 2.8 Populate CMDB and Verify Configuration Details

    The purpose of this task is to populate and verify the CI records in the CMDB.
    CI Librarian/Analyst

    CI Owner

    CM Process Manager
    R


    C

    I
    Begin populating the CMDB with CI types and associated attributes. Use incremental approach to build out one CI type at a time and verify with the CI Owner before proceeding to the next. For example, using servers, identify all the servers and then identify all the attributes and owners associated with each one, initiate mapping and populate the CMDB with the CI type and configuration details, and verify the relationship mapping between servers and other components is correct with the CI Owner.
Configuration Identification (ITSM) Cross-Functional Flow Diagram
  1. The following figure illustrates the Configuration Identification workflow.

    Figure 2.150.2-11

    This is an Image: 60767014.gif

    Please click here for the text description of the image.

CM 3.0: Configuration Control (ITSM)
  1. This activity ensures that the CI records are maintained and updated accurately in the CMDB with a corresponding RfC for change control.

    ID Task Name and Description Role RACI Duties
    CM 3.1 Review RfC

    The purpose of this task is to review the RfC and determine the nature of change and ensure that all required information is complete and accurate. This may require additional requirements elicitation.
    CI Librarian/Analyst R Review the RfC to determine the nature of change to the CI record and verify that all required information is complete and accurate. This may require contacting the requestor for additional requirements elicitation.

    Note:

    An RfC is submitted to change a CI record in the CMDB.

    D 3.1 Is the RfC Valid?

    Determine whether the RfC is valid—complete, accurate, and actionable.
    CI Librarian/Analyst

    CI Owner
    R


    I
    Determine if the RfC is valid:
    • If “Yes”, go to CM3.2.

    • If “No”, go to CM3.3.

     

    Note:

    If the source of the request is not from the CI Owner, the RfC must be validated to ensure that it is an authorized change. If not, the RfC is rejected.

    CM 3.2 CI Attribute Validation

    The purpose of this task is to validate the proposed CI attributes.
    CI Librarian/Analyst

    CI Owner
    R


    C
    Validate the requested change to the CI record and its attributes and ensure the defined information for the attribute is valid. Requirements include authorized source, scope of the CMDB, and mandatory attributes for submission.
    CM 3.3 Reject RfC

    The purpose of this task is to disposition the RfC if the task cannot be completed.
    CI Librarian/Analyst

    CI Owner
    R


    I
    If the task cannot be completed, reject the RfC.

    Update the RfC with reasons and details of any issues found.
    D 3.2 Attributes valid? CI Librarian/Analyst

    CI Owner
    R


    I
    Determine whether the attributes are valid or not:
    • If “Yes”, Update CMDB

    • If “No”, go to CM3.4.

     

    Note:

    Invalid CI attributes are returned to the CI Owner to resolve the discrepancy and the RfC is rejected

    CM 3.4 Investigate Discrepancy

    The purpose of this task is to investigate the discrepancy.
    CI Owner R Investigate and resolve the discrepancy that has been identified and submit a new RfC for the update.
Configuration Control (ITSM) Cross-Functional Flow Diagram
  1. The following figure illustrates the Configuration Control workflow.

    Figure 2.150.2-12

    This is an Image: 60767015.gif

    Please click here for the text description of the image.

CM 4.0: Configuration Status Accounting & Reporting (ITSM)
  1. This activity ensures that the CI records are maintained and updated accurately by generating status on CI information.

    ID Task Name and Description Role RACI Duties
    CM 4.1 Review Service Request for Reports

    The purpose of this task is to ensure that all required information to create the report is complete and accurate.
    CI Librarian/ Analyst R Review service request for nature and type of report.

    Note:

    The following instructions are applicable for infrastructure services affecting the CMDB records. This may also require additional requirements elicitation from users. The report request may be recurring or ad hoc. This request is submitted as a Service Request under the Request Fulfillment Process. This activity pertains to generating reports from the CMDB.

    D 4.1 Is Service Request Valid? CI Librarian/Analyst R Determine if the Service Request is valid:
    • If “Yes”, go to D4.2.

    • If “No”, go to CM4.2.

     

    Note:

    Ensure that Service Request is complete, accurate, and actionable.

    D 4.2 Is Service Request for Standard Report? CI Librarian/Analyst R Determine if the Service Request is valid:
    • If “Yes”, go to CM4.4.

    • If “No”, go to CM4.3.

     

    Note:

    Standard and Topology Reports may also be generated from a CMDB client application, if available. If so, the Service Request may be closed and the Requestor directed to the client application.

    CM 4.2 Reject Service Request

    The purpose of this task is to disposition the Service Request if the task cannot be completed.
    CI Librarian/Analyst R If the task cannot be completed, reject the task.

    Update the Service Request with reasons and details of any issues found.
    CM 4.3 Create Custom Report

    The purpose of this tasks is to create a custom report based on the requirements from the customer.
    CI Librarian/ Analyst R Create a special query based on the selected data from the custom report requirements.

    Note:

    Custom report requires special queries and creation of a new report format that existing standard reports cannot be easily configured with new data requirements.

    CM 4.4 Generate CI Report

    The purpose of this task is to generate the standard or custom report.
    CI Librarian/ Analyst R The report or query is run against the CMDB and/or target sources, and data is collected in the standard or custom report format.
    CM 4.5 Distribute Report to Stakeholders

    The purpose of this task is to distribute the report to various stakeholders for their review and analysis on the CI record updates and changes.
    CI Librarian/ Analyst R Provide the report to stakeholders and close the Service Request.

    For recurring reports, ensure that the report is generated automatically and distributed per the requirements.

    Note:

    It is at the discretion from each individual stakeholder for any actions taken from the report. The objective of this report is to provide information about the CIs.

Configuration Status Accounting & Reporting (ITSM) Cross-Functional Flow Diagram
  1. The following figure illustrates the Configuration Status Accounting & Reporting workflow

    Figure 2.150.2-13

    This is an Image: 60767016.gif

    Please click here for the text description of the image.

CM 5.0: Configuration Verification & Audit (ITSM)
  1. This activity ensures that CI records are verified and audited for data quality and integrity.

    ID Task Name and Description Role RACI Duties
    CM 5.1 Verify for Changes

    The purpose of this task is to verify for changes of CI records in CMDB.
    CM Process Manager R Generate report to review changes to CMDB data and identify source of the change, specifically associated with an RfC.

    Note:

    Prerequisite is to identify and select specific CI types, sub-types, and attributes for review. Reports are supported by metrics and measurement reports that provide overall statistical information on the data.

    CM 5.2 Verify for Data Integrity

    The purpose of this task is to verify for data integrity of CI records in the CMDB.
    CM Process Manager R Generate report to review for:
    • Unregistered components

    • Missing components (previously registered components)

    Note:

    Prerequisite is to identify and select specific CI types, sub-types, and attributes for review. Reports are supported by metrics and measurement reports that provide overall statistical information on the data.

    CM 5.3 Verify for Data Quality

    The purpose of this task is to verify for data quality of CI records in the CMDB.
    CM Process Manager R Generate report to review for:
    • Completeness (i.e., required fields and recommended fields)

    • Correctness (i.e., duplicate CIs, orphan CI relationships, staleness/old CIs)

    • Compliance (i.e., desired state based on standard configuration for each CI)

    Note:

    Prerequisite is to identify and select specific CI types, sub-types, and attributes for review. Reports are supported by metrics and measurement reports that provide overall statistical information on the data.

    D 5.1 Issues Found? CM Process Manager R Determine if any issues found based on the 3 verification checks:
    • If “Yes”, go to CM5.4.

    • If “No”, go to CM5.5.

    CM 5.4 Identify and Document Discrepancies

    The purpose of this task is to identify discrepancies for each of the 3 quality checks.
    CM Process Manager R Identify, analyze, and document any discrepancies for each of the 3 quality checks.
    CM 5.5 Generate Verification Report

    The purpose of this task is to document and summarize the findings in a Verification Report.
    CM Process Manager

    CI Librarian/Analyst

    CM Process Owner

    CI Owner
    R


    I


    I


    I
    Generate a Verification Report to document the overall status and for any discrepancies and corrective actions required to reconcile the discrepancies, where appropriate.

    Distribute the Verification Report to key stakeholders.

    Note:

    The Verification Report is delivered to key stakeholders that have responsibility for resolving the discrepancies and taking corrective actions.

    CM 5.6 Initiate CI Audit

    The purpose of this task is to initiate the CMDB audit, either through a service request or based on an audit plan. The audit verifies each individual CI.
    Configuration Auditor

    CM Process Manager

    CI Librarian/ Analyst
    R


    C


    I
    From the audit plan, identify whether the universe or sample of CIs that will be audited, including CI types or sub-types. Identify the audit against the CI baselines, CI attributes, and/or CI relationships. Identify additional criteria, as needed.

    Gather the CI data from the target source and generate report for review/analysis.

    Note:

    Normally, the CMDB audit is automatically triggered on a periodic or scheduled basis based on an audit plan established between the CM Process Manager and Configuration Auditor. Additionally, the CMDB audit may be triggered through a service request from management or Change Evaluation where configuration audits should be considered before and after a major change or release. Pre-requisite for the Periodic Audit is to establish an audit plan, identifying the criteria and CIs that need to be audited on a scheduled basis. A verification is conducted by the CM Process Manager that is separate from the external audit. This is to ensure and maintain the quality and accuracy of the CI records in the CMDB.

    CM 5.7 Reconcile and Evaluate Data

    The purpose of this task is to reconcile and evaluate the collected data from the CMDB.
    Configuration Auditor R Reconcile and compare collected CI data against what is stored in the CMDB.
    D 5.2 Unregistered Component Detected? Configuration Auditor R Determine if an unregistered components is detected:
    • If “Yes”, go to CM5.8.

    • If “No”, go to D5.3.

    Note:

    An unregistered component (non-registered or inaccurately registered CIs) may be detected in cases where the item cannot be match and found in the CMDB.

    D 5.3 Component Missing? Configuration Auditor R Determine if a component is missing:
    • If “Yes”, go to CM5.8.

    • If “No”, go to D5.4.

    Note:

    If a component cannot be discovered during an audit, it may have been lost, misplaced, or removed (for example, the CI has not been connected to the network for some period of time.)

    D 5.4 Discrepancy Found? Configuration Auditor R Determine if any discrepancies are found between the CI record in the CMDB and the actual data:
    • If “Yes”, go to CM5.8.

    • If “No”, go to CM5.9.

    Note:

    Based on the comparison between the CI record in the CMDB and the actual data from the audit, one or more discrepancies may be detected.

    CM 5.8 Investigate Discrepancy

    The purpose of this task is to review and investigate the discrepancy.
    Configuration Auditor R Investigate, identify, and record the mismatch between the CI record the actual CI in more detail. This includes investigating the attributes and relationships.

    Note:

    Based on the discrepancy, a CI may need to have an associated change record.

    CM 5.9 Generate Audit Report

    The purpose of this task is to document the discrepancy, findings, and recommendations.
    Configuration Auditor

    CM Process Manager

    Configuration Librarian/Analyst

    CM Process Owner
    R


    I


    I


    I
    Generate audit report:
    • Summarize the audit results

    • Summarize the findings and recommendations

    Distribute to key stakeholders that will have responsibility in addressing and improving the process and data.

    Note:

    The Audit Report is delivered to key stakeholders that have responsibility for resolving the discrepancies and taking corrective actions.

Configuration Verification & Audit (ITSM) Cross-Functional Flow Diagram
  1. The following figure illustrates the Configuration Verification & Audit workflow.

    Figure 2.150.2-14

    This is an Image: 60767008.gif

    Please click here for the text description of the image.

Configuration Identification Index and Document Versioning Guidance

  1. The following sections below provides the guidance for assigning Configuration Identification Index and Document Versioning for documentation CIs.

Configuration Identification Index (CII) Assignment

  1. The CII is composed of 5 fields: Config-, ID-, Index-, Ver-, and Date. The fields are separated by a hyphen and when joined, make up the CII. For example, the figure below illustrates how the CII is decomposed for (1) OS:IT:EO:DMPG-CHT-CCM_Charter-V1.0-01012020 and (2) DMPG:PDM:ITSTP-WKS-CM_Worksheet-V1.0.0-01012020.

    1. The “Configuration (Config)” field is defined as the CI Owner and will contain the IRS organizational symbols or external Service Provider as input. A CI Owner is the one that owns and is responsible for the specific CI and the primary validation point for information related to that CI. The CI Owner responsibilities include maintaining ownership of the CI, reports changes in ownership, and reports changes in the CI information. The field size is limited to 30-characters. If the organizational symbol exceeds 30-characters, it will need to be truncated starting from the left to meet the 30-character requirement. For example: OS:IT:EO:DMPG:PDM:ITSTP-

    2. The “Identification (ID)” field is defined as the CI Classification. The CI Classification contains the CI type and specific class of a CI (or CI Subtypes). For documentation CIs, the various subtypes are requirements, designs, and test. This field will contain the CI Subtypes via a drop-down list that is defined in the CI classification table under the “ID (CI Classification) “tab of the CM Worksheet. This field is limited to 7-characters in length. For example, OS:IT:EO:DMPG:PDM:ITSTP-ICD-

    3. The “Index”field is defined as the CI reference containing the abbreviated description of the CI. This field is limited to 20-characters in length. For example, OS:IT:EO:DMPG:PDM:ITSTP-ICD-ProjectX_ICD-

    4. The “Version (Ver)” field is defined as the version of the CI. For documentation CIs, Section 2.150.2.3.2 Document Versioning, provides the instructions for version file management. . In addition, when finalizing the document version, all draft versions listed in the “Change History” or “Record of Changes” table will need to be removed and its nature of changes summarized under the final version. The version must start with a “V” in the CII, such as “V1.0, V2.0, etc. This field is limited to 7-characters in length. For example, OS:IT:EO:DMPG:PDM:ITSTP-ICD-ProjectX_ICD-V1.0-

    5. The “Date” field is defined as the date of creation or update of the CI. For documentation CIs, Section 2.150.2.3.2 Document Versioning, also provides the instructions for dates as part of version file management. The date must be 8-characters long, such as, “01012017” or “12012017”. For example, OS:IT:EO:DMPG:PDM:ITSTP-ICD-ProjectX_ICD-V1.0-01012020

  2. For documentation CIs, the CII should be inserted as a footer in the document. Any changes to the document, the Ver- and Date- fields will need to be updated on the CII.

Document Versioning

  1. Document versioning refers to the use and management of multiple versions of a document. This is generally known as file(s) versioning or file version management, for general file types. The fundamental aspect of document versioning is tracking changes and tracking the creation of multiple document versions such as by numbering file versions in successions. Below are the document version control guidelines, and as illustrated in the figure below.

    Figure 2.150.2-16

    This is an Image: 60767012.gif

    Please click here for the text description of the image.

    1. Document Date
      - Date the document is created or revised, and is incorporated as part of the CII footer in the document and appears on every succeeding page.

    2. Version Number
      - Current version number is created, and is incorporated as part of the CII footer in the document and appears on every succeeding page.

    3. First Draft
      a. The first draft of a document will be Version 0.1.
      b. Subsequent drafts will increase by “0.1” in the version number ( e.g., 0.2, 0.3, 0.4, …0.9, 0.10, 0.11).
      c. Date will change with each draft version.
      d. All changes will be documented in the change history table.

    4. Final Version
      a. Document will be deemed as final after all reviewers have provided final comments and dispositioned.
      b. The first final version of a document will be Version 1.0.
      c. Change to the latest date when the document becomes final.
      d. Remove draft versions(s) and only final version remain with “Initial release” language in the change history table.

    5. Revisions to a Final Version
      a. Final documents undergoing revisions will be Version X.1 for the first draft of the previous final revision.
      b. While the document is under review, subsequent draft versions will increase by “0.1” (e.g., Version 1.1, Version 1.2, Version 1.3).
      c. Date will change with each draft version.
      d. All changes will be documented in the change history table.

    6. Subsequent Finals
      a. When the revised document is deemed final, the version will increase by “1.0” over the version being revised (e.g., draft Version 1.3 will become final Version 2.0).
      b. Change to the latest date when the document becomes final.
      c. Remove draft version(s) and only final version remain with summary of changes from previous draft(s) in the change history table.
      d. Subsequent final documents will have an increase of “1.0” in the final version number (2.0, 3.0, 4.0, etc.)

    Note:

    For Revisions to a Final Version, if the changes were minor (editorial) and released within the same year, it is acceptable to use the next final version as Version 1.1, Version 1.2, etc. for multiple releases. However, if the changes are substantial and requires stakeholder review, then Step 5 through Step 6 must be followed.