2.150.2 Configuration Management (CM) Process

Manual Transmittal

December 10, 2019

Purpose

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

Material Changes

(1) Converted using the new IT IRM Process Section Template

(2) Incorporated all the CM Procedures

(3) Updated instructions for Software Configuration Management

(4) Added instructions for ITIL Configuration Management

(5) Various editorial changes

Effect on Other Documents

IRM 2.150.2 dated September 25, 2013 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

(12-10-2019)


Chief Information Officer

Program Scope and Objectives

  1. This document 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.

  2. 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 operational 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.

  3. For the purposes of this document, the process scope and objective for this Configuration Management is primarily based on the ITIL framework. However, the interfaces with Software Configuration Management is also described and outlined in order to manage the CI throughout the development and operations lifecycle.

Background

  1. A process is defined as “A set of related activities that accomplish a common goal”. This document defines the process description, process goal and objectives, role definitions, policies and other process related attributes.

  2. Information systems are typically dynamic, causing the system state to change frequently because of upgrades to hardware, software, firmware or modifications to the surrounding environment in which a system resides. Industry standards and best practices such as the Institute of Electrical and Electronic Engineers (IEEE) Standard for Software Configuration Management in Systems and Software Engineering, ITIL and International Organization for Standardization/International Electrotechnical Commission (ISO/IEC) 20000:2011 Information Technology Service Management (ITSM), National Institute of Standards and Technology (NIST) Special Publications (SP) 800-128 Guide for Security-Focused Configuration Management including those issued by the Government Accountability Office (GAO) and the Office of Management and Budget (OMB), 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.

  3. 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 Description
  1. Configuration Management is the process responsible for providing accurate and complete configuration information about the infrastructure components, including their attributes and relationships, to support other ITSM processes, such as Change Management and Release & Deployment Management.

  2. 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.

  3. 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.

Goal
  1. The process goal describes a specific purpose or achievement toward which the efforts of the process are directed. Each process has a specific focus and when combined with the other processes, forms a comprehensive framework for delivering and managing services.

  2. The goal is to provide accurate information on the attributes of IT service related components and their relationships to enhance the effectiveness of the other 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 amongst CIs.

Objectives
  1. 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 Service Management processes: Incident Management, Problem Management, Change Management, Release Management, Capacity Management, Availability Management, IT Service Continuity Management, and Service Level Management.

    • 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 infrastructure, CIs or component CI that need to be managed are reflected on the CMDB.

Disciplines
  1. Configuration Management is performed within the context of the 5 common disciplines that are applicable in development, operations, and security environment (see Figure 1). Although Configuration Management has shared goal and objective in identifying, managing, and controlling the CIs across the environments, its purpose and application is entirely different.

  2. 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.

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

  4. 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.

    Figure 2.150.2-1

    This is an Image: 60767001.gif
     

    Please click here for the text description of the image.

Configuration Item
  1. 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 IRS CM Process and whether the CIs are in-scope of the IRS CMDB.

    Figure 2.150.2-2

    This is an Image: 60767002.gif
     

    Please click here for the text description of the image.

Authority

  1. All proposed changes to this document must be submitted in writing, with supporting rationale, to the Demand Management & Project Governance (DMPG) in Enterprise Operations.

  2. DMPG is responsible for the development, implementation, and maintenance, of this process.

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.

    Name Description
    Configuration Management (CM) Process Owner 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 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 ITSM 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 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 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 model (physical and logical model) for the CIs

    • Provides input to the process scope and procedures.

    Configuration Management System (CMS)/Tools Administrator 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 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 The Project Manager is responsible for the planning and execution of a project.
    Project Configuration Manager (Software Configuration Management) The Project Configuration Manager (formerly CM Representative) is assigned and supports the Project Manager and has the following responsibilities:
    • Develops, documents, and implements a configuration management plan for each information system that:
      • Addresses roles, responsibilities, and configuration management processes and procedures;
      •Defines the configuration items for the information
      • Establishes the means for identifying configuration items throughout the system development life cycle and a process for managing the configuration of the configuration items.

    • 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 (Software Configuration Management) 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 (CCB) A group of people responsible for evaluating and approving/disapproving proposed changes to configuration items, and for ensuring implementation of approved changes.
    Engineering or Technical Review Board A committee that ensures the technology choices made by the organization are the best option for all groups in the organization.

Program Management and Review

  1. Policies outline a set of plans or courses of action that are intended to influence and determine decisions or actions of a process. Policies provide an element of governance over the process that provides alignment to business vision, mission and goals.

    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 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.
    Rationale 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 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.
    Rationale The process must meet operational and business requirements.
    Technology and Tools Statement 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:
    • Universal Configuration Management Database (uCMDB)

    • Universal Discovery

    • uCMDB Browser

    • uCMDB Configuration Manager

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

Program Control

  1. Activities involved in ensuring a process is predictable, stable, and consistently operating at the target level of performance.

Controls
  1. Process controls represent the policies and guiding principles on how the process will operate. Controls provide direction over the operation of processes and define constraints or boundaries within which the process must operate.

    Name Description
    Scope The scope of the Configuration Management process. Includes identification of what is included in and what is excluded from the Configuration Management process.
    CM Policies Policies and criteria for the inclusion of a configuration component and its attributes in the CMDB.
    Configuration Audits The frequency of configuration audits
    Management Reports The frequency and distribution for regularly produced management reports.
    Change Management Policies Change Management Policies and procedures.
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
    Application Mapping Modeling CIs to represent key business services and applications.
    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.
    Discovery The process of finding and collecting information about the hardware, software and some relationships between these components. At the IRS, we use both agentless and agent-based discovery, which enables us to discover running software as well as collect inventory information that provides details around all the information on a given server or device.
    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.
    Instance-Based Model An instanced-based model or logical model is built by selecting a business CI to serve as its basis, and manually adding CIs to the model.
    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.
    Modeling Selecting CIs to appear in a view and enabling a collection of CIs that can be reused with other perspectives to create different views.
    Pattern-Based Model A pattern-based model or physical model is built using a Topological Query Language (TQL) query to determine the CIs included in the model.
    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.
    Premium Service List Critical Filing Season applications that have been approved by the Infrastructure Executive Steering Committee (IESC) for premium level incident management services.
    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.
    Universal CMDB A CMDB and Discovery software product produced by MicroFocus supporting ITIL Configuration Management and which features a CMDB, as well as a mechanism for the automatic discovery of IT infrastructure components, such as computers, network devices and composing relationships between them.
Acronyms
  1. This table lists commonly used acronyms in the Configuration Management process.

    Acronyms Description
    CAB Change Advisory Board
    CCB Configuration Control Board
    CI Configuration Item
    CM Configuration Management
    CMDB Configuration Management Database
    CMMI Capability Maturity Model Integrated
    COH Computer Operations Handbook
    DMPG Demand Management and Project Governance
    ELC Enterprise Life Cycle
    EOTCR End of Test Completion Report
    FCA Functional Configuration Audit
    FIPS Federal Information Processing Standards
    GAO Government Accountability Office
    ICD Interface Control Document
    IEEE Institute of Electrical and Electronics Engineers
    IESC Infrastructure Executive Steering Committee
    IRS Internal Revenue Service
    ISO/IEC International Organization for Standardization/International Electrotechnical Commission
    IT Information Technology
    ITPAL IT Process Asset Library
    ITIL Information Technology Infrastructure Library
    ITSM IT Service Management
    MTTR Mean Time to Restore
    NIST National Institute of Standards and Technology
    OMB Office of Management and Budget
    PBL Product Baseline
    PCA Physical Configuration Audit
    PSL Premium Service List
    RfC Request for Change
    SCM Software Configuration Management
    SP Special Publication
    SQL Structure Query Language
    TQL Topological Language
    uCMBD Universal Configuration Management Database
    UD Universal Discovery

Related Resources

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

    • IRM 2.150.1 Configuration Management Policy

    • IRM 2.125.1 Change Management Policy

    • IRM 2.125.2 Change Management Process

    • IEEE Standard for Configuration Management in System and Software Engineering

    • ITIL Service Transition, 2011 Edition, Chapter 4.3 Service Asset and Configuration Management

    • ISO/IEC 20000-1:2011 IT Service Management, Section 9.1 Configuration Management

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. List below the training resources available for this process:

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

    • Configuration Identification, ELMS Course #17494

    • Configuration Management Combo Course, ELMS Course #64877

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 defines the key process activities and process interfaces for the Configuration Management process.

    Figure 2.150.2-3

    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) A Request for Change is the record of a Change proposal that is worked through the Change Management process. Change Analyst
    Service Request A user request for information or fulfillment and usually handled by the Service Desk. 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
    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 Owner, CM Process Manager, Project Manager
    CI Defined as project/system components and their attributes and relationships used in the delivery and maintenance of IT Services. CM Process Manager, CI Librarian/Analyst, CI Owner, Configuration Auditor
    CM Worksheet A CI register that list all the documentation (project and configuration baselines) and hardware and software that is required for the project and used to develop, test, deliver, monitor, control, and support Information Technology. CM Process Owner, CM Process Manager, Project Manager, Project Configuration Auditor
    CI Structure Chart The CIS Chart is used to identify IRS applications and/or infrastructures for creating the service model. CM Process Manager, CI Librarian/Analyst
    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. CM Process Manager, Project Manager
    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.
    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.
    A report summarizing the results of a CMDB audit, highlighting revealed differences between CMDB records and the installed CIs.
    CM Process Owner, CM Process Manager, CI Librarian/ Analyst, CI Owner, Project Manager

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.
     

    ID Name Description
    CM 1.0 Configuration Management Planning This activity establishes the Configuration Management Plan that describes the CM activities 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. In addition, this activity also establishes the Configuration Data Model that defines the structure and information model for the CMDB.
    CM 2.0 Configuration Identification This activity does 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 and the CI selection and identification of software and document libraries.
    CM 3.0 Configuration Control Configuration Control is the activity 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.
    CM 4.0 Configuration Status Accounting & Reporting Status Accounting is the reporting activity of Configuration Management. It is used to produce regular and ad-hoc reports on the current, past and future status of the infrastructure and the CIs under the control of Configuration Management.
    CM 5.0 Configuration Verification & Audit Configuration Verification and Audit is the audit, review and verification of the physical existence of CIs to check that they are correctly recorded in the CMDB
    SCM 5.1 and SCM 5.2 Configuration Audit (Software Configuration Management) Configuration Audit is a Software Configuration Management process activity and its objective is to maintain the integrity of the configuration baselines. Configuration audits confirm that the resulting baselines and documentation conform to the special standard or requirements. Configuration audits 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.

Procedure

  1. A procedure provides the step by step instructions, or tasks, in how to perform each activity in the process and usually applies to a single role that will be responsible in performing the task.

CM 1.0: Configuration Management Planning
  1. This Activity establishes the CM Plan and Configuration Data Model for the CMDB.

    ID Task Name and Description Role RACI Duties
    CM 1.1 Prepare for CM

    The purpose of this task is to prepare the Configuration Project Manager and CM participants for executing the CM process under the Enterprise Life Cycle (ELC) project.
     

    Note:

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

    Project Configuration Manager


    CM Process Manager




    Project Configuration Manager
    R


    I





    R
    Identify CM participants involved in the product/project development and ensure that all CM participants receive training and request for training using the service catalog in the CM Front Door. If training has been completed, skip this step.




    Identify ELC Milestone dates for MS-1/2 for delivering the CM Plan for Milestone Readiness Review and Milestone Exit Review.
    D1.1 Develop CM Plan?

    Determine if an individual CM Plan will need to be created or leveraged from Organizational-level CM Plan:
     
    • Project-level CM Plan – defines CIs that will be managed for the project.

    • Program-level CM Plan – defines CIs that will be managed for the program that consist of multiple projects.

    • Subordinate Organizational-level CM Plan – defines CIs that will be managed by sub-ordinate organization based on its portfolio of projects and/or products.

     

    Note:

    An Organizational-level 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. The Organizational-level CM Plan should only be reviewed/updated when there are major structural or process changes or every three (3) years for re-certification.

    Project Configuration Manager R Determine if the CM Plan will be created, tailored, or leveraged from the organizational-level CM Plan by contacting the Organization CM Plan Owner for guidance.

    If the CM Plan will need to be tailored or created, go to CM-1.2.
    CM 1.2 Identify Change Authority

    The purpose of this task is to identify an existing change authority, specifically a Configuration Control Board (CCB) that will be responsible for change and control of the project/product CIs

    Note:

    No new CCB must be created for transition to the Change Advisory Board (CAB).

    .
    Project Configuration Manager


    Project Configuration Manager
    R



    R
    Identify an existing CCB that will be responsible for the decisions on changes to the CI.

    Obtain existing CCB Charter including Engineering or Technical Review Board (ERB/TRB) to document the scope of authority, roles and responsibilities, and structure in the CM Plan under the Configuration Control Section.
    CM 1.3 Develop the CM Plan

    The purpose of this task is to complete the CM Plan.
    Project Configuration Manager












    Project Configuration Manager


    Project Configuration Manager






    Project Configuration Manager CM Process Manager


    Project Configuration Manager
    R













    R




    R








    R

    C


    R
    Obtain the CM Plan Template from the CM Front Doorand complete all required information. The CM Plan will address the requirements of the Configuration Identification, Configuration Control, Configuration Status Accounting & Reporting, and Configuration Verification & Audit as appropriate and should be tailored to the level of CM chosen during the project initiation (e.g., smaller projects do not need as much documentation as large projects). Include boards (e.g., CCB, TRB) as referenced from their charters.


    Identify CIs that will be managed and controlled for the project/program/organization.


    Identify the key project/process artifacts for the 3 types of baselines (functional, allocated, or product) for FCA/PCA (at discretion of the project) activities. Note that these project/process artifacts will also be listed in the CM Worksheet.




    Submit completed CM Plan for review and approval using the CM Front Door SharePoint site.



    Identify and/or establish project repository for storage of all project artifacts. Ensure that each project artifact contains appropriate configuration item unique identifier, called Configuration Identification Index (CII) with appropriate version and date to establish and update the baseline.
    CM 1.4 Establish CMDB Data Model The purpose of this task is to define the structure and information model of the CMDB. This includes:
    • Model of IT services (breakdown of services into service components)

    • CI relationships types

    • Definition of CI types

    • Definition of CI attributes

    • Identification of data sources

    • CI Owner

    Note:

    When using a COTS product for the CMDB, the Configuration Data Model may already be pre-defined by the COTS application and cannot be modified or updated.

    CM Process Manager/ CMS/Tools Administrator




    CMS/Tools Administrator CM Process Manager

    R




    I
    Define and establish CMDB data model and identify information that will populate that model. For example, identifying the CI Types and required attributes for the CI types.


    Baseline the CMDB data model.
    D 1.2 Update CMDB Data Model or Information?
     

    Note:

    After initial population of the CMDB, the CMDB Data Model may be updated through a change request. Changes to the data model may result from a new type of CI introduced in the IT infrastructure as a result of a release.

     

    Note:

    This decision may not apply if using a COTS product for the CMDB since the CMDB Data Model cannot be changed. Only the information in the CMDB Data Model, such as changing the CI Type and its attributes.

    CM Process Manager R Determine whether the Configuration model should be updated –
    • If “Yes”, go to D1.3; otherwise, process ends.

    D 1.3 New CI-Type Needed?





    The CM Process Manager collaborates with the CMS Tools/Administrator for impacts on adding a new CI-Type and potential capacity issues for adding new CI records. The CM Process Manager will also assess the value of adding the new CIs into the CMDB and elevates discussion with the CM Process Owner.
    CM Process Manager


    CM Process Owner

    CMS/Tools Administrator
    R



    A


    C
    Determine if the request is to add a new CI-Type –
    • If “Yes”, consult with the CMS Tools/Administrator for impacts and assess the value of adding the new CI-Type. Discuss with the CM Process Owner for a decision, and go to D1.4.

    • If "No", go to D1.5.

    D 1.4 Approve or Disapprove Adding a New CI Type

    The CM Process Manager obtains the decision from the CM Process Owner whether to approve/disapprove the changes. If approved, the CM Process Manager notifies the CMS Tools/ Administrator to add the new CI-Type to the CMDB Data Model.
    CM Process Manager

    CM Process Owner

    CMS/Tools Administrator
    R

    A


    I
    Determine whether the New CI Type will be Approved –
    • If “Yes”, the CM Process Manager notifies the CMS Tools/Administrator of the CM Process Owner decision for creating a new CI-Type, go to CM1.5

    • If “No”, process ends.

    D 1.5 Modify CI Type?

    The CM Process Manager determines requested change(s) to the CI record for the CI-Type, and collaborates with the CMS Tools/Administrator for impacts. The CM Process Manager assessed the value and need for adding/updating the changes to the existing CI record.
    CM Process Manager

    CMS/Tools Administrator
    R


    C
    Determine whether the existing CI-Type will be modified or not-
    • If “Yes”, go to CM1.6

    • If “No”, process ends.

    CM 1.5 Create New CI Type

    The purpose of this task is to add a new CI type to the CMDB data model.
    CMS/Tools Administrator R Add new CI type including the definition of the CI attributes.
    CM 1.6 Configure CI Type

    The purpose of this task is to modify the existing CI type.
    CMS/Tools Administrator R Create or modify the definition of the CI type. This includes:
    • CI subtypes

    • Attribute definitions

    • CI relationships types

    • Naming conventions

    • Business rules on required fields

  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.

Configuration Management Planning Cross-Functional Flow Diagram
  1. The Configuration Management Planning workflow is illustrated in the following diagram below.

    Figure 4 - Configuration Management Planning Swim Lane Diagram

    Figure 2.150.2-4

    This is an Image: 60767004.gif
     

    Please click here for the text description of the image.

CM 2.0: Configuration Identification
  1. This activity establishes and maintains CIs and its Model.

    ID Task Name and Description Role RACI Duties
    CM 2.1 Complete CI Structure Chart (CIS) for Application Modeling

    The purpose of this task is to identify and select the CIs based on the project application that will be modeled, and complete the CIS Template for application modeling.
    Configuration Project Manager



    Configuration Project Manager/ CM Process Manager

    Configuration Project Manager







    Configuration Project Manager Configuration Project Manager/ CM Process Manager




    Configuration Project Manager
    R





    R
    I




    R








    R
    R


    I





    R
    If ELC Project, identify ELC Milestone dates for MS-3/4A for delivering CIS Chart and CM Worksheet for the ELC Milestone Readiness Review and Milestone Exit Review.

    Obtain CIS Chart Template from the IT PAL and complete all required information.


    Obtain technical architecture diagrams for the key application project. This includes Interface Control Document (ICD), and related project artifacts that defines the project goal, scope, and objective.


    Identify supporting infrastructure and application interfaces for the application project.


    Submit the completed CIS Chart for review and approval using theCM Front Door SharePoint site.

    Create a task in the RfC to model the application based on the requirements completed on the CIS Chart and include all the technical architecture diagrams, ICDs, and related artifacts describing the application.
    CM 2.2 Identify and Register CIs in the CM Worksheet

    The purpose of this task is to identify and register CIs to be controlled in the CM Worksheet. Elements to be controlled will normally include the software code and associated documentation. Documents could include requirements specifications, designs, user guides, test suites, test results, and user lists. For documentation CIs, assign unique identifiers, called Configuration Identification Index (CII) and determine the type of configuration baselines (i.e., functional, allocated, and product baselines) for the project. The CII is also used for traceability. Identify and register the structure of the intermediate or complete software products including related hardware.
    Any addition, alteration, or deletion to the approved baseline is deemed a change, and is subject to change control. Baselines, plus the approved changes from those baselines, constitute the current configuration identification. Each of the baselines established during a software lifecycle controls subsequent software development. The following are typical configuration baselines that are established during the life of a software project.
    • Functional Baseline - Established by the acceptance or approval of the software or system specification. This baseline typically corresponds to the completion of the software requirement review.

    • Allocated Baseline – Established by approval of the software requirements specification. This baseline typically corresponds to the completion of the software specification review.

    • Product Baseline – Established by approval of the product specification following completion of the last formal functional configuration audit (FCA).

     

    Note:

    Refer to Section 3.0 for CII and Document Versioning Guidance.

    Configuration Project Manager

    Configuration Project Manager




    Configuration Project Manager


    Configuration Project Manager

    CM Process Manager


    Configuration Project Manager
    R



    R




    R


    R


    I



    R
    Obtain CM Worksheet Template from the IT PALand complete all required information.

    Identify and list all functional, allocated, and product baseline work products into the CM Worksheet, including CI document owners.

    Identify and register the structure of the intermediate or complete software products including related hardware.

    Submit the completed CM Worksheet for review and approval using the CM Front Door SharePoint site.



    Update the CM Worksheet when work products and infrastructure items (hardware/software) are finalized. This will be used for FCA/PCA audit activities and validation from the application model.
    CM 2.3 Assess and Finalize CM Worksheet CM Process Manager



    Configuration Project Manager
    R




    R
    Review and assess the CM Worksheet to ensure that work products are finalized and that infrastructure items are recorded.

    Based on the assessment, finalize the work products including infrastructure items, where applicable.
    CM 2.4 Initiate Population of CMDB

    The purpose of this task is to initiate population of the CMDB after the CMDB Data Model has been completed.

    The CMDB is initially populated through automated “discovery” and/or manually. In the automated discovery, building the CMDB begins with discovering CIs and relationships using the UD. The following steps are:
    • UD Probe range and boundary configurations

    • Discovery: Internet Protocol, Network

    • Discovery: Host and Resources

    • Discovery: Databases, Clusters

    • Discovery: Virtual Environments

    • Discovery: Business Applications

    Note:

    Automatic discovery is conducted daily to populate the CMDB.

    CI Librarian/ Analyst




    CI Librarian/ Analyst

    CI Librarian/ Analyst


    CI Owner


    CI Owner


    CI Librarian/ Analyst

    R




    R


    R



    R

    R


    R
    C

    Populate the CMDB with CI-related information. This can be performed manually or using an automated “discovery” tool.


    Assign CI Owners to each CI.

    Validate new CIs and discoverable attributes that have been added to the CMDB

    Update non-discoverable attributes and add/verify relationships.


    Set status to Active and baseline.
    CM 2.5 Review RfC for Modeling or Add New Application CI

    The purpose of this task is to ensure that all required information to create/update the model or add a new application CI is complete and correct. This may require additional requirements elicitation and update to the RfC.
    CM Process Manager

    CI Librarian/ Analyst

    R


    C

    Review the RfC to verify that all required information to create the model or add new application CI is complete and correct.

    Ensure that all necessary documentation, including but not limited to IP Address List, Server Lists, host names, environment information, ICD, and technical schematics are included as part of the request.
    D 2.1 Is the RfC Valid?


    Determine whether the RfC is valid—complete, accurate, and actionable.
    CM Process Manager

    CI Librarian/Analyst

    R


    C

    If the task is valid, go to D2.2; otherwise, go to CM-2.6.
     
    D 2.2 Is the request to add a new application CI to the CMDB? CM Process Manager
    R

     

    If the task is to add a new application CI to the CMDB, go to CM-2.7;

    If the task is to create a new model, go CM-2.8
    CM 2.6 Reject RFC

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


    CM Process Manager CI Librarian Analyst

    R

    C

    R

    I

    If the task cannot be completed, reject the task.


    Update the RfC with reasons and details of any issues found.
    CM 2.7 Create a New Application CI

    The purpose of this task is to create and add a new Application CI to the CMDB and identify related CIs.

    Note:

    An internal quality control is conducted by the CI Librarian/Analyst to ensure that the CI record is complete, attributes have valid information and relationships identified, when posted on the CMDB.

    CI Librarian/ Analyst










    CI Librarian/ Analyst

    CI Librarian/ Analyst


    CI Owner



    CI Owner/CI Librarian/ Analyst

    R













    R


    R




    R


    R
    C

    Initiate the UD application to probe using a set of IP addresses. An “IP Address CI” is created upon a successful connection. The UD attempts to connect to the host resource(s) and upon successful connection, initiates the automatic discovery of all related CIs associated with the service and adds the CI records in the CMDB.



    Assign CI Owners to each CI.

    Validate new CIs and discoverable attributes that have been added to the CMDB.


    Update non-discoverable attributes and add/verify relationships.


    Set status to Active and baseline.
    CM 2.8 Conduct Mapping and Modeling

    The purpose of this task is to create/update the model, and flag Premium Service List (PSL) applications
    CI Librarian/ Analyst
    CI Owner


    CI Librarian/ Analyst CI Owner


    CI Owner CI Librarian/ Analyst


    CI Librarian/ Analyst


    CI Librarian/ Analyst CI Owner


    CI Librarian/ Analyst CI Owner

    CI Librarian/ Analyst

    R
    C


    R
    C



    R
    I

    R


    R



    C

    R



    C
    R
    Determine if a Physical Model or Logical Model will be created.

    Select and map the CIs to the views and create the model, and then flag the PSL applications.


    Review model for accuracy.


    Re-run discovery as necessary (for physical model).

    Create perspective-based views of modeled application.



    Verify model with CI Owner.



    Set snapshot and close RfC.
    CM 2.9 Baseline and Maintain the Model
    The purpose of this task is to baseline the model and validate its accuracy.


    For PSL applications, re-certification will need to be performed prior to the beginning of each Filing Season. A schedule for re-validation for PSL models will be determined by the CM Process Manager.


    For non-PSL applications, re-certification will need to be done biannually. A schedule for re-validation for non-PSL models will be determined by the CM Process Manager.
    CI Librarian/ Analyst CI Owner

    Configuration Project Manager
    CM Process Manager



    CI Librarian/ Analyst CM
    Process Manager

    CI Owner CI Librarian/ Analyst




    CI Librarian/ Analyst CM Process Manager

    R
    C


    I
    I





    R
    C



    R
    C



    R

    I

    Obtain concurrence and baseline the model and CIs.


    For ELC Projects, monitor and ensure that the model is completed prior to MS-4B exit, including providing status to the ELC for milestone exit approvals.

    Implement re-validation schedule of the PSL and non-PSL models.



    Validate and obtain concurrence on the model. For any changes to the model, complete and submit the RfC.

    Implement schedule and conduct discovery to automatically update the CI records in the CMDB.
Configuration Identification Cross-Functional Flow Diagram
  1. The Configuration Identification workflow is illustrated in the following diagram below.

    Figure 2.150.2-5

    This is an Image: 60767005.gif
     

    Please click here for the text description of the image.

CM 3.0: Configuration Control
  1. This activity ensures that the CI records are maintained and updated accurately in the CMDB with a corresponding RfC for changes to CI baselines.

    ID Task Name and Description Role RACI Duties
    CM 3.1 Evaluate and Disposition Change Package

    The purpose of this task is to evaluate and disposition (approve/disapprove) the RfC

    Note:

    Changes to controlled CIs must use the Change Management process. A Change Package is created resulting from the review and assessment of the technical teams and Technical Review Board (TRB) or Engineering Review Board (ERB) where applicable.

    CCB

    TRB/ERB

    Project Configuration Manager
    R

    C

    I
    Review and disposition the RfC and Change Package.
    D 3.1 Is the RfC approved?


     

    Note:

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

    CCB


    TRB/ERB

    Project Configuration Manager
    R


    I

    I
     
    Determine and disposition the RfC:

    If the RfC is approved, go to CM-3.4.

    If the RfC is not approved, the RfC is returned and the process ends.
    CM 3.2 Review RfC




    The purpose of this task is to review the RfC and determine the nature of changes to the CI Record.

    Note:

    Changes to controlled CIs must use the Change Management process.


    CM Process Manager



    CI Librarian/ Analyst
    R




    C
    Review the RfC to verify that all required information to update the CI Record. This may require contacting the CI Owner and Change Coordinator to discuss changes to the CI.
    D 3.2 thru D 3.4 Determine whether the RfC is valid—complete, accurate, and actionable—ensure appropriate tasks are routed to the appropriate activities. CM Process Manager

    CI Librarian/Analyst
    R



    C
    If the RfC task(s) is NOT valid, go to CM-3.3.


    If the RfC task(s) is to update the CMDB Data Model or add/change the CI Type, go to A1-Configuration Management planning.

    If the RfC task(s) is to create or update the model, go to A-2 Configuration Identification.

    If the RfC task(s) is to update the CI Record(s), go to CM-3.4
    CM 3.3
    Reject RfC

    The purpose of this task is to disposition the RfC if the task cannot be completed.
    CM Process Manager

    CI Librarian/Analyst
    R



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


    Update the RfC with reasons and details of any issues found.
    CM 3.4 Update and Re-Baseline CI Record in CMDB

    The purpose of this task is to update and re-baseline the CI record attributes and relationships for the applicable CI.

    Note:

    An internal quality control is conducted by the CI Librarian/Analyst to ensure that the CI record is complete, attributes have valid information and relationships identified, when posted on the CMDB.

    CI Librarian/Analyst CI Owner
















    CI Librarian/Analyst
    CI Owner
    R


    C















    R

    C
    Modify the configuration details in the CMDB. Configuration modifications include:
    • Status (items transferred from test to production or to retirement)

    • Location (moves)

    • Relationships and dependencies

    • Installation of software on the item

    • Transfer of ownership

    • Etc.



    Obtain concurrence and re-baseline CI record updates.
Configuration Control Cross-Functional Flow Diagram
  1. The Configuration Control workflow is illustrated in the following diagram below.

    Figure 2.150.2-6

    This is an Image: 60767006.gif
     

    Please click here for the text description of the image.

CM 4.0: Configuration Status Accounting & Reporting
  1. This activity ensures that the CI records are maintained and updated accurately in the CMDB with a corresponding RfC for changes to CI baselines.

    ID Task Name and Description Role RACI Duties
    CM 4.1 Capture CSA Information

    The purpose of this task is to review and identify all the necessary items that will produce the report that reflects the proposed, currently approved, and validated versions of the work products. Some of these may already have been recorded in the CM Worksheet and may require updating on the latest approved versions. These include but not limited to:
    • 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.

    • Items associated with the project to satisfy contracts, accomplish assignments or provide information to the project.

    • 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.

    • Items that will be used for application, execution, implementation, or sustainment.


    Project Configuration Manager
    R Identify and review all necessary items that will produce the report. This includes those listed in the CM Worksheet.
    CM 4.2
    Generate and Distribute CSA Reports

    The purpose of this task is to generate the CSA reports on an as-needed basis for project use and for reviews. Distribute the CSA reports to the stakeholders. Archive the CSA reports to provide an audit trail. Examples of information typically presented in the CSA reports include, but are not limited to the following items:
    • Change Request (CR) status

    • Deficiency or Defect Report (DR) status

    • Action Item status

    • Change implementation status

    • System and subsystem versions

    • Document status (i.e., Requirements Documents, Design Documents, Test Documents, Plans, etc.)

    • Release composition (versions of system files and documents that are contained in a particular release)

    • Test status

    Project Configuration Manager


    Project Stakeholders
    R




    C
    Produce and distribute the report to stakeholders.


    Review the reports for accuracy and validity of the information.

     
    CM 4.3 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. This may also require additional requirements elicitation from the various stakeholders such as the CM Process Manager, CI Owner, Project Manager, or Configuration Auditor. The report request may be recurring or ad hoc. This request is submitted as a Service Request under the Request Fulfillment Process.

    Note:

    This activity pertains to the CI records in the CMDB.

    CM Process Manager
    CI Librarian/ Analyst
    R


    C
    Review service request for nature and type of report.
    D 4.1 thru D 4.2 Determine whether the Service Request is valid—complete, accurate, and actionable—and type of report.
     

    Note:

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

    CM Process Manager



    CI Librarian/ Analyst
    R




    I
    If the Service Request is NOT valid, go to CM-4.4.



    If the Service Request is for a Custom Report, go to CM-4.5.

    If the Service Request is for a Standard Report, go to CM-4.6.
    CM 4.4 Reject Service Request

    The purpose of this task is to disposition the Service Request if the task cannot be completed.
    CM Process Manager


    CI Librarian/Analyst
    R



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

    Update the Service Request with reasons and details of any issues found.
    CM 4.5 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.
    CM 4.6 Generate the 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.7 Distribute Report to Stakeholders


    The purpose of this task is to distribute the report to the various stakeholders for their review and analysis on the CI record updates and changes.

    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 the status of CIs.

    CI Librarian/ Analyst

    CI Librarian/ Analyst
    CM Process Manager
    R


    R

    I
    Distribute report to stakeholders.

    For recurring reports, ensure that the report is generated automatically and distributed per the requirements.
Configuration Status Accounting & Reporting Cross-Functional Flow Diagram
  1. The Configuration Status Accounting & Reporting workflow is illustrated in the following diagram below.

    Figure 2.150.2-7

    This is an Image: 60767007.gif
     

    Please click here for the text description of the image.

CM 5.0: Configuration Verification & Audit (CMDB)
  1. This activity ensures that CI records are accurate and that all CIs are identified and recorded in the CMDB.

    ID Task Name and Description Role RACI Duties
    CM 5.1 and D 5.1 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.

    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 CIs that need to be verified and/or audited on a scheduled basis.
     

    Note:

    An internal verification and reconciliation is conducted by the CI Librarian/Analyst separate from the external audit. This is to ensure and maintain the quality and accuracy of the CI records in the CMDB.

    Configuration Auditor
    Configuration Auditor






    CM Process Manager






    Configuration Auditor
    CI Librarian/ Analyst
    R




    R





    C





    R

    C
    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 prepare Audit Log.
    CM 5.2 Reconcile and Verify Data
    The purpose of this task is to reconcile and verify 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?
    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.
    Configuration Auditor R If an unregistered component is detected, update the status in the Audit Log to “Unknown” and go to CM-5.3; otherwise, go to D-5.3.
    D 5.3 Component Missing?

    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.)
    Configuration Auditor R If the component is missing, update the status in the Audit Log to “Missing” and go to CM-5.3; otherwise go to D5.4
    D 5.4 Discrepancy Found?

    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.
    Configuration Auditor

    CM Process Manager
    R


    I
    If a discrepancy is found on the CI record between the CMDB and the actual data, update the status in the Audit Log to “Discrepancy” and go to CM-5.3; otherwise go to CM 5.5.
    CM 5.3 Investigate Discrepancy

    The purpose of this task is to review and investigate the discrepancy.

    Each CI needs to have an associated change record.
    Configuration Auditor R Investigate, identify, and record the mismatch between the CMDB and the actual CI in more detail. This includes investigating the attributes and relationships.
    CM 5.4 Determine Corrective Action

    The purpose of this task is to document the discrepancy and determine appropriate actions. An incident must be created and assigned to the CI Owner for executing the actions.
    Configuration Auditor
    Configuration Auditor
    CM Process Manager
    CI Owner
    R


    R

    I

    I
    Document the discrepancy.


    Determine appropriate actions and create an Incident record and go to CM-5.6.
    CM 5.5 Update and Close Audit

    The purpose of this task is to update the CI with the audit status and last audit date in the CMDB.
    Configuration Auditor

    Configuration Auditor CM Process Manager
    R



    R
    C
    Update CI with the audit status and last audit date in the CMDB.


    Close Audit.
    CM 5.6 Review Incident Record

    The purpose of this task is to review and analyze the incident record and validate the audit findings.
    CI Owner R Review and Validate the audit findings.
    D 5.5 Is the Incident Valid? CI Owner
    Configuration Auditor
    R

    I
    If the exception is valid, go to CM-5.7; otherwise, close incident record and inform the Configuration Auditor to update the status on the audit.
    CM 5.7 Create RfC to Resolve and Update CI Record

    The purpose of this task is to resolve the discrepancy on the CI record through the Change Management procedures.
    CI Owner R Create RfC to initiate changes and updates to the CI record.
Configuration Verification & Audit (CMDB) Cross-Functional Flow Diagram
  1. The Configuration Verification & Audit workflow is illustrated in the following diagram below.

    Figure 2.150.2-8

    This is an Image: 60767008.gif
     

    Please click here for the text description of the image.

SCM 5.1: Configuration Audit - Functional Configuration Audit
  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, and customer representative, that will be involved in the audit.
    Pre-requisites to commence the audit:
    • The development of a CI has been completed satisfactorily

    • The item has achieved the performance and functional characteristics specified

    • Its operational and support documents are complete and satisfactory

    • After completion of the Execution Phase—i.e., test phase after completion of the Test Readiness Review.

    Project Manager

    Project Manager

    Project CM
    Project Configuration Auditor
    Customer Representative
    R

    R



    I

    I


    I
    Plan the audit.

    Identify and notify the resources that will support the audit.
    SCM
    5.1.2
    Gather FCA Review Materials


    The purpose of this task is to identify and gather review materials
    Project CM



    Project CM
    R



    R
    Gather all applicable material for review. Use the CM Worksheet 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 CM


    Project CM

    Project CM


    Project CM

    Project CM



    Project Manager
    R
    R

    R


    R



    R


    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.
    The following inputs are required:
    • Functional requirements document such as the software requirements specification or general requirements specification

    • System design documents such ICD, design document, database specifications, etc.

    • Test Plan

    • Test scripts

    • End of Test Completion Report (EOTCR)

    • Other input as specified by the functional requirements and planning documents

    Project Configuration Auditor R 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.

    CM 5.1.5 Capture 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. 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.
    Project CM

    Project CM

    Project CM

    Project Manager
    R

    R

    R

    C
    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.
Configuration Audit - FCA Cross-Functional Flow Diagram
  1. The Configuration Audit - FCA workflow is illustrated in the following diagram below.

    Figure 2.150.2-9

    This is an Image: 60767009.gif
     

    Please click here for the text description of the image.

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 (PBL) 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, and customer representative, that will be involved in the audit.

    Pre-requisites to commence the audit:
    • Work Products in the Product Baseline

    • Project Configuration Management Plan

    Project Manager

    Project Manager


    Project CM





    Project Configuration Auditor




    Customer Representatives

    R


    R



    I





    I






    I
    Plan the audit


    Identify and notify the resources that will support the audit.
    SCM
    5.2.2
    Gather PCA Review Materials
    The purpose of this task is to identify and gather review materials.
    Project Configuration Manager
    Project Configuration Manager
    R


    R
    Gather all applicable material for review. Use the CM Worksheet 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

    Project Configuration Manager


    Project Configuration Manager
    Project Configuration Manager
    R

    R

    R

    R

    R


    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.

    The following inputs are required:
    • List of approved changes to CI

    • Test scripts

    • Test reports

    • Test results of all test performed

    • Manuals, such as Computer Operators Handbook (COH) and User Guides

    • FCA Audit results

    • All open Action Items from previous reviews

    • Any other documentation as required by the Project Configuration Auditor

    Project Configuration Auditor R 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.

    SCM 5.2.5 Capture 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. 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.
    Project CM

    Project CM


    Project CM

    Project Manager
    R


    R



    R


    C
    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.
Configuration Audit - PCA Cross-Functional Flow Diagram
  1. The Configuration Audit - PCA workflow is illustrated in the following diagram below.

    Figure 2.150.2-10

    This is an Image: 60767010.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 to document configuration items.

Configuration Identification Index (CII)

  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 CII below is decomposed in Figure 1: OS:IT:EO:DMPG-CHT-CCM_Charter-V1.0-01012017 and DMPG:WCCE:ITSTP-WKS-CM_Worksheet-V1.0.0-01012017.

    Figure 11 - CII Structure

  2. 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.

  3. The “Identification (ID)” field is defined as the CI Classification. The CI Classification contains the CI type and specific class of a CI. A CI is any component of an IT infrastructure (e.g., hardware and software), including documentation, which is (or is to be) under the control of Configuration Management and therefore subject to formal Change Control. A CI is further classified into types of classes (or CI Subtypes). For example, for a documentation CI, the various subtypes are reports, charters, plans. 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.

  4. The “Index”field is defined as the CI reference containing the abbreviated description of the CI. For example, in the case of documentation CIs, this field will contain the following: ACA_Project_Mgt_Plan. This field is limited to 20-characters in length.

  5. 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, for example “V1.0, V2.0, etc. This field is limited to 7-characters in length.

  6. The “Date” field is defined as the date of creation or update of the CI. For document CIs, Section 3.2 Document Versioning also provides the instructions for dates as part of version file management. The date must be 8-characters long, for example, “01012017” or “12012017”

  7. 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 noted in Figure 12.

  2. 1. Document Date
    a. The author of the document will ensure the 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
    The author of the document will ensure the current version number is created or revised 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 have an increase of “0.1” in the version number, e.g., 0.2, 0.3, 0.4, …0.9, 0.10, 0.11.

    c. All changes will be documented in the change history table.
    4. First Final
    a. The author will deem a document final after all reviewers have provided final comments and the comments have been dispositioned.
    b. The first final version of a document will be Version 1.0. Include the date when the document becomes final; and drafts will be removed from change history and final versions only remain with “Initial release” language in the change history table.
    c. Subsequent final documents will have an increase of “1.0” in the version number (1.0, 2.0, etc.).
    5. Revisions to a Final Version
    a. Final documents undergoing revisions will be Version X.1 for the first version of the revisions. While the document is under review, subsequent draft versions will increase by “0.1”, e.g., 1.1, 1.2, 1.3, etc. When the revised document is deemed final, the version will increase by “1.0” over the version being revised, e.g., the draft 1.3 will become a final 2.0.
    b. A list of changes from the previous draft or final documents will be kept.
    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., the draft 1.3 will become a final 2.0.
    b. Substantive changes from the previous draft will be summarized in the final document version. Drafts will be removed from the change history and only final versions remain.

    Figure 2.150.2-12

    This is an Image: 60767012.gif
     

    Please click here for the text description of the image.