Part 2. Information Technology

Chapter 150. Configuration and Change Management

Section 5. Configuration Verification for IRS Applications (PSL and Non-PSL) Process

2.150.5 Configuration Verification for IRS Applications (PSL and Non-PSL) Process

Manual Transmittal

June 20, 2024

Purpose

(1) This transmits revised IRM 2.150.5, Configuration Verification for IRS Applications (PSL and Non-PSL) Process.

Material Changes

(1) IRM 2.150.5.1.8 Training. Removed outdated references.

(2) IRM 2.150.5.2.1 Main Process Diagram. Revised main process diagram.

(3) IRM 2.150.5.2.2 Inputs. Added new process inputs.

(4) IRM 2.150.5.2.3 Outputs. Added new process output.

(5) IRM 2.150.5.2.5.1 Identify Scope of Application CIs for Verification. Changed the scope of the process to include all IRS applications.

(6) IRM 2.150.5.2.5.3 Plan and Prepare Project Requirements. Replaced references to individual user guides with link to SharePoint site containing all user guides.

(7) IRM 2.150.5.2.5.4 Conduct Application Verification and Updates. Expanded requirements for the verification activities.

Effect on Other Documents

IRM 2.150.5 dated March 17, 2023 is superseded

Audience

This IRM 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 IRS IT enterprise hardware, software, and applicable documentation.

Effective Date

(06-20-2024)


Rajiv Uppal
Chief Information Officer

2.150.5.1 (06-20-2024)

Program Scope and Objectives

  1. Purpose. This IRM supplements the configuration verification process under IRM 2.150.2 Configuration Management Process. This process specifically supports the configuration verification of IRS Applications (Premium Service List (PSL) and Non-PSL) to ensure that CI records in the Internal Revenue Workflow Optimization Request and Knowledge System (IRWORKS) are accurate for Filing Season Readiness and IT Service Management (ITSM) processes.

  2. Audience. This IRM is applicable to all IT organizations, contractors, and other stakeholders having responsibility for configuration, management, oversight, and successful day-to-day operations of the IRS IT enterprise hardware, software, and applicable documentation.

  3. Policy Owner. Demand Management & Project Governance (DMPG) Division, within Enterprise Operations (EOps) - IT.

  4. Program Owner. Governance & Resource Management Branch, within DMPG - EOps - IT.

  5. Primary Stakeholders. IT organizations having responsibility for ownership and management of IRS applications and infrastructure are practitioners of this process.

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

2.150.5.1.1 (04-26-2021)

Background

  1. The PSL Revalidation (original process name) was incepted in 2015 and its purpose was to verify IRS critical systems, called PSL application, information that were selected by the IT organization for premium incident response and restoration services. It is a configuration verification activity performed as part of the Filing Season Readiness to ensure that PSL application information is accurate. The PSL Revalidation results are also used by the Enterprise Infrastructure Currency (EIC) and ITSM processes, such as Change, Incident, and Problem Management.

  2. The PSL Revalidation was expanded to Non-PSL applications to include configuration verification activities for all other IRS applications.

  3. This process will formally be called Configuration Verification for IRS Applications (PSL and Non-PSL) for the combined but separate efforts.

2.150.5.1.2 (04-26-2021)

Authority

  1. The IRMs listed below establishes the authority for this process:

    • IRM 2.150.1 Configuration Management Policy

    • IRM 2.125.1 Change Management Policy

2.150.5.1.3 (04-26-2021)

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. The table below describes the roles and responsibilities for this process.

    Process Role 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
    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 IT processes

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

    • Designs and generates configuration status reports; including management reports
    Configuration Item (CI) Owner The CI Owner is accountable for all activities that directly affects their CI(s). This role is also responsible for all CM 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

    CI Owners may be Application Owners, Project Owners, Server Owners, or Support Groups.
    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 and application models for CIs

    • Provides input to the process scope and procedures.
    Premium Service List (PSL) Process Manager Responsible for development, management, and maintenance of the PSL Process and facilitating review and approval of proposed applications to the EOps Governance Board as a Premium Service application.
    Server Signature File (SSF) Team Responsible for coordinating and implementing SSF change request submitted by CI Owners to update the application name and SSF attributes in Asset Management database and IRS Tier II servers.
    EOps Governance Board Responsible for approving/disapproving proposed changes by CI Owners.
2.150.5.1.4 (04-26-2021)

Program Management and Review

  1. The IT CM Program Management Office (PMO) shall manage and evaluate the process based on the following guiding principles:

    1. Process Management. Configuration Management will have a single Process Owner and a separate Process Manager, responsible for implementing 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.

    2. People. Roles and responsibilities for the process must be clearly defined and appropriately staffed with people having the required skills and training. The mission, goals, scope and importance of the process must be clearly and regularly communicated by upper management to the staff and business customers of IT. All IT staff (direct and indirect users of the process) shall be trained at the appropriate level to enable them to support the process. It is imperative that people working in, supporting or interacting with the process in any manner understand what they are supposed to do. Without that understanding Configuration Management will not be successful.

    3. Process. Modifications to the 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, and Roles and Responsibilities along with documented process flows. The process will be kept straight forward, rational, and easy to understand. The process must meet operational and business requirements.

    4. Technology and Tools. 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. Technology and tools should be used to augment the process capabilities, not become an end themselves.

2.150.5.1.5 (04-26-2021)

Program Controls

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

2.150.5.1.5.1 (04-26-2021)
Controls

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

    Name Description
    Baselines Documented agreed descriptions of the attributes and/or specifications of a CI, at a point in time, which serves as the basis for defining change.
    Change Management Policies Policies and mandates for change control of CIs.
    CM Policies Policies and mandates for management and control of CIs.
    Configuration Reports The frequency and distribution for regularly produced configuration management reports on the status of CIs.
    Configuration Verification The frequency of configuration verification to maintain the integrity of the CI and its attributes and relationships.
    Enterprise Architecture Mandates Requirements and mandates for all IRS applications to be registered and updated in the As-Built-Architecture.
    Taxonomy Defined standards for naming and classifying CIs including terms and definitions.
2.150.5.1.5.2 (04-26-2021)
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 this 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.

  3. Enterprise and local Configuration Management processes, including Configuration Management tool owners, must produce metrics and measurement reports to measure the effectiveness and efficiency of the Configuration Management process.

2.150.5.1.5.3 (04-26-2021)
Tailoring Guidelines

  1. This process will not be tailored.

2.150.5.1.6 (04-26-2021)

Terms and Acronyms

  1. This table lists commonly used terms for this process.

    Term Definition
    Application Collection of software programs that automates a business function and its data provided by a taxpayer or third party to the IRS regarding the applicant's status. Additional descriptions are listed below:

    • An IT component of a system that utilizes IT resources to store, process, retrieve or transmit data or information using IT hardware and software.

    • Each Application may be part of more than one IT Service.

    • An Application runs on one or more servers or clients.

    • Its functionality supports business processes.

    • Interactive applications support business end users directly.

    • Batch applications manage data, and generate reports, etc., as part of a business process.

    • Applications include IRS-specific functionality in support of business requirements as well as generic end-user functionality.

    • Generic functionality includes common desktop applications its functionality include highly complex capabilities that are nevertheless common to many different types of enterprise, such as accounting or customer- relationship-management capabilities.

    • Generic capabilities are typically provided by COTS applications, whereas IRS-specific capabilities generally involve custom-developed applications.
    As-Built-Architecture Represents the IRS’ Current Production Environment (CPE) with business applications, external systems, and external trading partners. It also includes interfaces, key attributes, and information related to Privacy and Civil Liberties Assessments. The ABA allows Business Analysts and Information Technology (IT) professionals to view the CPE from both technical and business perspectives using IRS’ Enterprise Life Cycle’s (ELC) Six Domains of Change, to see interrelationships between technological and business domains, and get information necessary to make informed decisions.
    Configuration Verification Configuration Management activity responsible for confirming that configuration management records and CIs are complete, consistent, and accurate.
    Configuration Management Database (CMDB) A 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.
    Non-Premium Service List (Non-PSL) Applications that are not in the PSL are called Non-PSL. These applications do not have a distribution system for inviting service providers and management to an escalation. E-mails are sent to service providers selected by the person taking the IMR role. The Service Operations Specialist (SOS) send the emails. Non-PSL escalations are set to a lower priority than PSL escalations. Non-PSL tickets are worked as capacity permits.

    • A SOS will leave a Non-PSL escalation if a PSL outage requires an escalation and IMS doesn’t have the capacity to work both.
    Premium Service List (PSL) PSL applications are listed on the Premium Service List (PSL) and are linked to a distribution system which utilizes Derdack for automated calls/invites and e-mail distribution lists to an escalation. The SOS initiate the Derdack system and send the e-mail. This enables the IT Operations Command Center (ITOCC) to contact service providers and management quickly with accountability. Incident Managers of Record (IMR) are also trained and used to facilitate Assessment, Technical Service Restoration Team (SRT), and Management SRT calls for PSL applications.

    • PSL outages are the SOS highest priority.
    Sub-application Is a part of a larger application (please refer to Application definition). Additional descriptions listed below:

    • Its functionality supports business processes.

    • Collection of one or more software programs that automates a business function.

    • Can reference other sub-applications to any depth.
    Server Signature File (SSF) Process The SSF delivers valuable server data to Configuration Management System tools providing additional insight into IRS Enterprise Operations infrastructure. It validates server attributes (Project, GSS, and ENV), ensure data quality and integrity, and deploy the SSF file to existing and new EOps Tier II servers.
    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

  2. This table lists acronyms used in this IRM.

    Acronym Description
    ABA As-Built-Architecture
    AM Asset Management
    CI Configuration Item
    CM Configuration Management
    CMDB Configuration Management Data Base
    CPE Current Processing Environment
    CR Change Request
    EIC Enterprise Infrastructure Currency
    ENV Environment
    GSS General Support System
    IRWORKS Internal Revenue Work Optimization Request and Knowledge System
    PSL Premium Service List
    SSF Server Signature File
    UCMDB Universal Configuration Management Database
2.150.5.1.7 (04-26-2021)

Related Resources

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

    • IRM 2.15.1.2.1 As-Built-Architecture Architecture

    • IRM 2.17.1 Infrastructure Currency Policy for Software

    • IRM 2.125.2 Change Management Process

    • IRM 2.150.2 Configuration Management Process

    • Change Management Procedure

    • Server Signature File (SSF) Standard Operating Procedure

2.150.5.1.8 (04-26-2021)

Training

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

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

    • Change Management Process Overview, ITM Course #43161

2.150.5.2 (04-26-2021)

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.

2.150.5.2.1 (04-26-2021)

Main Process Diagram

  1. The Main Process Diagram illustrates the key process activities and process interfaces for Configuration Verification for IRS Applications (PSL and Non-PSL).

    Figure 2.150.5-1

    This is an Image: 75426001.gif

    Please click here for the text description of the image.

2.150.5.2.2 (04-26-2021)

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:

    Name Description Supplier
    Premium Service List List of approved PSL applications. PSL Process
    Asset Management (AM) Project Table List of projects/applications/services registered in AM, AM
    ABA Applications Report List of CPE applications registered in the ABA. As-Built-Architecture
    IRWORKS Server List List of Tier II servers associated with the application. IRWORKS
    IRWORKS Service List List of business and application services. IRWORKS
2.150.5.2.3 (04-26-2021)

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
    Verified and Updated CI Information Verified and updated application to server relationships, server inventory, server attributes, and service information. Application Owner

    CM Process Manager
    Status Report Status of configuration verification activity and results. Stakeholders
    SSF Change Request (CR) A record of a change proposal or corrections to the SSF attributes (Project, GSS, and ENV) that is worked through the Change Management process. Change Coordinator

    Change Analyst
    Incident Management Request (IMR) A record of an error that may impact the quality of service. Incident Analyst
2.150.5.2.4 (04-26-2021)

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. The following activities for this process are described below and corresponds to the high-level process flow diagram above.

    1. Establish Initial Scope of Application CIs for Verification. This activity establishes the initial scope of CIs for the process.

    2. Identify CI Ownership and Finalize Scope. This activity identifies CI ownership and finalizes the scope.

    3. Plan and Prepare Project Requirements. This activity establishes the plan, schedule, resources, roles/responsibilities, reporting, and expectations including preparing the tools and documentation to support the process.

    4. Conduct Application Verification and Updates. This activity implements the verification process including use of the SSF Process to correct the discrepancies.

    5. Generate Report and Close Out. This activity is responsible for reporting out the results of the activities and close out.

2.150.5.2.5 (04-26-2021)

Procedures for Configuration Verification for IRS Applications (PSL and Non-PSL)

  1. This procedure describes the tasks, roles, and responsibilities for the process.

2.150.5.2.5.1 (04-26-2021)
Establish Initial Scope of Application CIs for Verification

  1. This activity establishes the initial scope of application CIs that will be verified for its relationships, server inventory, and server attributes. The following tasks, performed by the CM PMO, are described below.

    1. (1) Identify Application CIs for Verification.

      1. For PSL Applications , obtain and review latest update of the Premium Service List.

        Note:

        PSL Applications are derived from the Premium Service List that is maintained by the PSL Process Manager.

      2. For Non-PSL Applications, define and select a sample of applications from the As-Built-Architecture (ABA), such from a particular ACIO, Filing Season Critical, etc, but exclude PSL applications.

      (2) Identify Application CIs for Scope.

      1. For Tier II PSL Applications, correlate against the IRS Project attribute from the IRWORKS Server List, and select only those supported by active (Installed status) Tier II servers.

      2. For Non-Tier II PSL Applications, correlate against the Business Service name from the IRWORKS Service List, and select only those that match or may have discrepancies in the name.

      3. For Tier II Non-PSL Applications, correlate the asset record (IRS Project, Environment, GSS, and Hostname) between Asset Management and IRWORKS Server List using the Project name and select only those that have discrepancies in the attributes.

      4. For Non-Tier II Non-PSL Applications, correlate the Business Service name from IRWORKS Service List against the Application acronym from the ABA and select only those that have discrepancies in the name.

      (3) Establish Initial Scope.

      1. Establish initial scope for PSL or Non-PSL applications.

2.150.5.2.5.2 (04-26-2021)
Identify CI Ownership and Finalize Scope

  1. This activity identifies and verifies CI Ownership and finalizes the scope for the process. The following tasks, performed by the CM PMO, are described below.

    1. (1) Identify CI Ownership.

      1. Identify and verify CI Ownership (i.e., Application Owner and Manager) information that will be responsible for the verification activities.

        Note:

        Source of CI Ownership information is in the ABA. Application Owners are called Content Providers and Managers (i.e., Frontline Manager and Senior Manager).

      2. If no CI Ownership is identified, exclude the application from the scope.

      (2) Finalize Scope.

      1. Establish final list of applications that have current CI Ownership information.

      2. Finalize scope and baseline.

2.150.5.2.5.3 (04-26-2021)
Plan and Prepare Project Requirements (PSL Only)

  1. This activity establishes the plan, schedule, resources, roles/responsibilities, reporting, and expectations including preparing the tools and documentation to support the process. The following tasks, performed by the CM PMO, are described below.

    1. (1) Establish Administrative Process for Verification

      1. Define and design administrative process (manual or automated) to conduct and collect verification results. For example, using desktop tools (e.g., Excel, Word, Email) to manually record or SharePoint solution to automatically record and self-certify verification activities.

        Note:

        For SharePoint solution, identify roles and permissions for each Application Owner that will have responsibility for update and certification. The existing SharePoint solution for this process is located in the PSL Revalidation Portal.

      (2) Identify Key Resources.

      1. Identify and verify support teams that may have a role in supporting the process. For example, those responsible for change management process (SSF Team), PSL process (PSL Process Team), and CMDB (ECMS Team).

      2. Identify supporting tools, such as IRWORKS and UCMDB Browser.

      (3) Establish or Update User Guides.

      1. Establish or update resource materials to support the process located in the PSL Revalidation Portal

      (4) Establish Measurement and Status Reporting Requirements.

      1. Determine what to measure and report.

      2. Identify data to measure and report.

      3. Design and establish measurement and report template.

      4. Determine reporting frequency.

      (5) Establish Project Schedule.

      1. Determine project start and end date, including extended deadlines, if necessary.

        Note:

        Align schedule with Enterprise Infrastructure Currency (EIC).

      2. Determine schedule for Project Pre-Kick Off Meeting and Kick Off Meeting.

      3. Determine schedule for status reporting.

      Conduct Pre-Kick-Off Meeting.

      1. Develop briefing materials for Project Pre-Kick Off Meeting and Kick-Off-Meeting.

      2. Define roles, responsibilities, and expectations.

      3. Schedule and conduct Project Pre-Kick Off Meeting with support teams.

2.150.5.2.5.4 (04-26-2021)
Conduct Application Verification and Updates

  1. This activity is responsible for establishing and implementing the verification activities to verify and certify the Application CI information.

    Conduct Project Kick-Off Meeting (PSL Only) (CM PMO).

    1. Schedule and conduct Project Kick-Off Meeting.

    2. Conduct training, as necessary.

    3. Prepare and distribute meeting minutes.

    Conduct Verification Activities (CI Owners).

    Note:

    CM PMO initiates the activities to begin.

    1. Review and verify the following information for accuracy:
      (1) Server inventory (for Tier II applications)
      (2) Server attributes (Project, GSS, and ENV) (for Tier II applications)
      (3) Business Service and naming standard
      (4) Application Service ENV allocation and naming standard

    2. Identify discrepancies.
      (1) Server inventory is not correct (e.g., missing server or incorrect server) (Tier II)
      (2) Server host name is not correct (Tier II)
      (3) Server attribute is not correct (i.e., Project, GSS and ENV assignment) (Tier II)
      (4) Business Service or Application Service naming standard is not correct
      (5) Business Service is not associated with an Application Service
      (6) Application Service is not associated with a Business Service
      (5) Application Service ENV is missing or not correct

      Note:

      For PSL applications, refer to the instructions provided in the PSL Revalidation Portal.

    Correct and Re-verify the Data, if applicable (CI Owners).

    1. For Tier II Applications:
      (1) Complete the SSF CR Initiator Worksheet Template to record the corrections.
      (2) Submit a SSF Change Request (CR).

      Note:

      Refer to the instructions for the SSF Process provided in the PSL Revalidation Portal. Only corrections to existing records should be made, not changes. A separate SSF CR must be submitted for changes to the record. The objective of this process is to review and correct the record to reconcile with the CI Owner’s record.


      (3) Record the SSF CR # in the PSL Revalidation Portal (for PSL only).
      (4) Verify updates in IRWORKS once the corrections have been implemented.
      (5) Close the CR.

    2. For Non-Tier II Applications:
      (1) Submit an IMR to “Configuration Management Application Support” assignment group
      (2) Record the IMR # in the PSL Revalidation Portal (for PSL only).
      (3) Verify updates in IRWORKS once the corrections have been implemented.
      (4) Close the CR.

    Certify the Verification (PSL Only) (CI Owners).

    1. Record the date the verification was completed in the PSL Revalidation Portal.

      Note:

      The PSL verification process is complete once the date of validation is recorded, not when the SSF CR or IMR is closed.

    Conduct Follow-Up (PSL Only) (CM PMO).

    1. Review verification status and identify those that have not completed the process.

    2. Determine if assistance is needed to initiate or complete the process.

    3. Send scheduled reminders to those that have not completed the process.

2.150.5.2.5.5 (04-26-2021)
Generate Report and Project Close Out

  1. This activity is responsible for summarizing and reporting out the results of the verification activities and project close out. The following tasks, performed by the CM PMO, are described below.

    Gather and Collect Data.

    1. Gather and collect results for each data sources.

      Note:

      Data collected from the defined administrative process (e.g. SharePoint), including from other tools such as IRWORKS.

    Analyze and Summarize Results.

    1. Aggregate data based on defined reporting requirements in the report template.

    2. Analyze and summarize cumulative results.

    3. Develop charts and tables to support the analysis and performance measurements.

    Generate Report and Project Close Out.

    1. Generate and release scheduled status and measurement reports to all stakeholders.

    2. On project close out (PSL Only) -
      (1) Conduct final summary and release final report.
      (2) Release all support teams.
      (3) Archive all resource materials.