2.100.2  Integrated Process Management Standardization Process

Manual Transmittal

May 30, 2014

Purpose

(1) This transmits revised IRM 2.100.2, Integrated Process Management (IPM), Integrated Process Management Standardization Process.

Material Changes

(1) (1)The following process roles were removed or retired: i.Associate Chief Information Officer (ACIO) Point of Contact (POC) ii.Executive Sponsor iii.Integrated Process Management (IPM) Process Owner iv.Reviewer v. Team Member

(2) Removed Team Review procedure.

(3) Revised Step 5: “Develop and/or Update Process or Procedure Asset” to “Tailoring the Process”. i.Removed the instructions for developing and/or updating procedure assets since there are no requirements to standardize procedure assets. ii.Provided additional instructions for tailoring or defining the process through the Procedure document. Only “Procedures” can be tailored, not the “Process”.

(4) Streamlined the review and approval process by eliminating additional process roles.

(5) Removed the following IRM assets (IRM Feedback Form and Form 2061) to eliminate confusion between IPM and IRM.

(6) Added Escalation Procedure.

Effect on Other Documents

IRM 2.100.2 dated October 2, 2013, is superseded.

Audience

The IPM Standardization Process is applicable to all Information Technology (IT) organizations, contractors, and other stakeholders having responsibility for developing IT business processes.

Effective Date

(05-30-2014)

Terence V. Millholland
Chief Technology Officer
Information Technology

2.100.2.1  (03-27-2014)
Process Description

  1. Integrated Process Management Standardization

2.100.2.1.1  (03-27-2014)
Introduction

  1. Introduction

2.100.2.1.1.1  (03-27-2014)
Administration

  1. All proposed changes to this document should be directed to the Enterprise Process Management Office (EPM), Business Relationship and Service Delivery, Enterprise Services under Information Technology (IT) owner of this process description and be pursued via the IPM process to clearly define interfaces, roles, responsibilities, and coordinate participation and collaboration between stakeholders.

2.100.2.1.1.2  (03-27-2014)
Purpose of Process Description

  1. This IPM Standardization process description describes what happens within the IPM process and provides an operational definition of the major components of the process. This description specifies, in a complete, precise, and verifiable manner, the requirements, design, behavior characteristics of the IPM process. The PD is a documented expression of a set of activities performed to achieve a given purpose. Tailoring of this process in order to meet the individual needs of each project is covered in the Tailoring Guidelines section of this document.

  2. For the purpose of this document, roles such as Author, Associate Chief Information Officer (ACIO) Point of Contact (POC), etc. are provided to describe a set of responsibilities for performing a particular set of related activities.

2.100.2.1.1.3  (03-27-2014)
Document Overview

  1. This document describes a set of interrelated activities, which transform inputs into outputs to achieve a given purpose, and states the guidelines that all projects should follow regarding the IPM process. The format and definitions used to describe each of the process steps of the IPM process are described below:

    • Purpose – The objective of the process step.

    • Roles and Responsibilities – The responsibilities of the individuals or groups for accomplishing a process step.

    • Entry Criteria – The elements and conditions (state) necessary to trigger the beginning of a process step.

    • Input – Data or material needed to perform the process step. Input can be modified to become an output.

    • Process Activity – The list of activities that make up the process step.

    • Output – Data or material that are created (artifacts) as part of, produced by, or resulting from performing the process step.

    • Exit Criteria – The elements or conditions (state) necessary to trigger the completion of a process step.

2.100.2.1.1.4  (03-27-2014)
Document Hierarchy

  1. The process document hierarchy is derived from the International Business Machines (IBM) Line of Visibility Enterprise Management (LOVEM) model. It consists mainly of a policy or directive, process, and procedure. The directive is the formal and mandatory order or official pronouncement on a policy, process, or procedure that establishes the organizational expectations. The directive may consist of one or more processes facilitated by process areas or business areas, and its process characteristics are defined by its process descriptions which may include one or more procedures for determining whether its provisions have been satisfied. The procedure document provides details of each activity and connects with other procedures. An example of the process document hierarchy is illustrated in Figure 2.100.2-1a, Simplified View of Document Hierarchy and Figure 2.100.2-1b, Complex View of Document Hierarchy.

    Figure 2.100.2-1a
    This image is too large to be displayed in the current screen. Please click the link to view the image.

    Figure 2.100.2-1b
    This image is too large to be displayed in the current screen. Please click the link to view the image.

2.100.2.1.1.5  (03-27-2014)
Process Classification

  1. This section describes the four (4) types of processes for classifying IT processes. The IPM Process classification is used for determining what is in-scope and includes the following:

    • Core Process - Critical to the mission of the organization.

    • Tailored Process - Core process adapted to fit the need of the organization.

    • Cross-functional Process - Non-Core/Non-tailored process with cross-functional impact.

    • Local Process - Non-core/Non-Tailored process with impact isolated to the functional area.

  2. Core processes are sanctioned by the Chief Technology Officer to establish and deploy the IT organization set of standard processes. These are processed through the IPM for standardization, centralization, and integration and facilitated through the IRM for institutionalization across the IT organization. The majority of the core processes align with the industry standards such as Capability Maturity Model Integration (CMMI), Information Technology Infrastructure Library (ITIL), and other processes institutionalized in the federal government. Tailored processes are modified versions of the core processes and require approval by the core process owner to maintain the defined organizational process requirements and are consider deviations from the standards. Directives and process descriptions for tailored processes are defined under the core processes. Core and tailored processes are in-scope of the IPM initiative.

  3. Cross-functional and local processes support the operational needs of the functional or business organization. Process descriptions are not required under IPM, but are highly encouraged for cross functional processes that impact other IT organizations. Cross-functional and local processes are not in-scope of IPM but can use the IPM standard templates to document their process.

  4. The table below, Types of Assets by Process, illustrates the types of process assets by process classification

    Types of Process Assets Core Tailored Cross-Functional Local
    IRM Yes No No No
    Directive Yes No No No
    Process Description Yes No Optional No
    Procedure Yes Yes Yes Yes
    Procedure Assets (e.g., procedure templates, checklist, forms, etc.) Yes Yes Yes Yes
    Process Aides (e.g., guides, manuals, etc.) Yes Yes Yes Yes
    Repository IT PAL and Link to IRM IT PAL IT PAL Local

2.100.2.1.2  (03-27-2014)
Process Overview

  1. Process Overview

2.100.2.1.2.1  (03-27-2014)
Work Products

  1. This section describes the work products needed to execute the process (known as inputs) as well as those produced by the IPM process (known as outputs).

2.100.2.1.2.1.1  (03-27-2014)
Work Products "Used" by this Process (Inputs)

  1. The following work products are used to assist in the implementation of the IPM process:

    • IPM Feedback Form (Optional)

    • IPM Directive (DIR) template

    • IPM Process Description (PD) template

    • IPM Procedure (PR) template

2.100.2.1.2.1.2  (03-27-2014)
Work Products "Produced" by this Process (Outputs)

  1. The following work products (artifacts) are produced by the IPM process and may be used as inputs to other processes, such as the Internal Revenue Manual (IRM) and IT Process Asset Library:

    • IRM Feedback Form – consolidated and completed (Optional)

    • IPM DIR – approved

    • IPM PD – completed

    • IPM PR – completed

    • IRS IT Business Process list – updated

2.100.2.1.2.2  (03-27-2014)
Roles and Responsibilities

  1. Many roles are involved in the IPM process. This section defines the roles used throughout this document.

    Role Description Definition of Responsibility
    Author
    • Develops and maintains documentation the process documentation for the Process Owner.

    • Conducts impact and assessment to affected stakeholders, and dispositions all comments.

    Integrated Process Management Office (IPMO) Analyst
    • Provides coaching and facilitation of the IPM process.

    • Conducts review of work products for compliance with IPM standards.

    • Updates IT Business Process List.

    Process Manager
    • Person accountable for the operational management of the process.

    • Plan and coordinate all process activities required to carry out, monitor, and report on the process.

    • Assign staff to required roles.

    • Manage process performance.

    • Work with Continual Service Improvement (CSI) Manager:

      • Review improvements

      • Prioritize improvements

    • This role is typically a manager.

    Process Owner
    • Person who is held accountable for ensuring that a process is fit for purpose.

    • Sponsorship, design, change management, and continual improvement of the process and its metrics.

    • Define process strategy.

    • Define process policies and standards.

    • Ensure process is documented.

    • Audit the process.

    • Ensure process resources are available during lifecycle.

    • Ensure proper process relevant communication.

    • Review improvement opportunities

    • This role may be a Director or Associate Chief Information Officer (ACIO).

2.100.2.1.2.3  (03-27-2014)
Process Flow Diagrams

  1. Process Flow Diagrams

    Figure 2.100.2-2
    This image is too large to be displayed in the current screen. Please click the link to view the image.

2.100.2.1.3  (03-27-2014)
IPM Standardization Process Steps

  1. Process Steps

2.100.2.1.3.1  (03-27-2014)
Step 1: Establish the Policy

  1. Establish the Policy

2.100.2.1.3.1.1  (03-27-2014)
Purpose

  1. The purpose of this process step is to establish a directive and implement a policy for a new IT business process that will be institutionalized and become a best practice or an enterprise standard in the Internal Revenue Service (IRS) IT organization.

2.100.2.1.3.1.2  (03-27-2014)
Roles and Responsibilities

  1. The Author is responsible for documenting the policy and requirements for the Process Owner.

2.100.2.1.3.1.3  (03-27-2014)
Entry Criteria

  1. Generally, Step 1- Establish the Policy occurs after the following events have occurred:

    • New IT business process has been pre-approved by their ACIO organization.

    • New IT business process is equivalent to an industry standard process (CMMI or ITIL), Federal government process, or an IRS IT organization process that will be institutionalized and become the enterprise standard or best practice in the IRS IT organization.

    • A Process Owner has been assigned to develop and maintain the new process.

2.100.2.1.3.1.4  (03-27-2014)
Input

  1. The following are inputs to this process step:

    • IPM Directive (DIR) template

    • IT Business Process List (located under Integrated Process Management in the IT PAL), IT PAL

2.100.2.1.3.1.5  (03-27-2014)
Process Activity

  1. Document the policy and requirements using the IPM Directive template.

  2. Review and obtain concurrence.

2.100.2.1.3.1.6  (03-27-2014)
Output

  1. The following are outputs to this process step:

    • Completed Directive document.

2.100.2.1.3.1.7  (03-27-2014)
Exit Criteria

  1. This process step is complete when:

    • A review and concurrence of the Directive document is complete.

2.100.2.1.3.2  (03-27-2014)
Step 2: Design and Model the Process

  1. Design and Model the Process

2.100.2.1.3.2.1  (03-27-2014)
Purpose

  1. The purpose of this process step is to define the scope and key activities of the process from beginning to end, including significant events, inputs, and outputs, using business process modeling.

2.100.2.1.3.2.2  (03-27-2014)
Roles and Responsibilities

  1. The Author is responsible for understanding the scope and requirements in order to design and model the process it.

2.100.2.1.3.2.3  (03-27-2014)
Entry Criteria

  1. Generally, in the Design and Model the Process, this step occurs after the following event have occurred:

    • A review and concurrence on the document has been completed.

2.100.2.1.3.2.4  (03-27-2014)
Input

  1. The following are inputs to this process step:

    • Completed Directive or Process Description.

    • Business Process Modeling Notation (BPMN) standard diagram elements.

2.100.2.1.3.2.5  (03-27-2014)
Process Activity

  1. Review the policy and process requirements.

  2. Design and develop a process model or process flow diagram.

  3. Test and validate the process model.

2.100.2.1.3.2.6  (03-27-2014)
Output

  1. The following are outputs to this process step:

    • Completed process flow diagram (PFD).

2.100.2.1.3.2.7  (03-27-2014)
Exit Criteria

  1. This process step is complete when:

    • Test and validation satisfy the requirements.

2.100.2.1.3.3  (03-27-2014)
Step 3: Document the Process

  1. Document the Process

2.100.2.1.3.3.1  (03-27-2014)
Purpose

  1. The purpose of this process step is to document the process from the process flow diagram (PFD).

2.100.2.1.3.3.2  (03-27-2014)
Roles and Responsibilities

  1. The Author is responsible for documenting the process using the Process Description or Procedure template.

2.100.2.1.3.3.3  (03-27-2014)
Entry Criteria

  1. Generally, the Document the Process step occurs after the following events have occurred

    • The PFD has been fully tested and validated on its sequencing and flow.

2.100.2.1.3.3.4  (03-27-2014)
Input

  1. The following are inputs to this process step:

    • Completed Directive and PFD.

    • IPM Process Description (PD) or Procedure (PR) template.

2.100.2.1.3.3.5  (03-27-2014)
Process Activity

  1. Review the PFD.

  2. Document the process using the IPM PD or PR template.

2.100.2.1.3.3.6  (03-27-2014)
Output

  1. The following are outputs to this process step:

    • Completed PD and or PR document.

2.100.2.1.3.3.7  (03-27-2014)
Exit Criteria

  1. This process step is complete when:

    • Test and validation satisfy the requirements.

2.100.2.1.3.4  (03-27-2014)
Step 4: Validate and Approve Documents

  1. Validate and Approve Documents

2.100.2.1.3.4.1  (03-27-2014)
Purpose

  1. The purpose of this process step is to validate and approve the new IT Business Process and establish it as a best practice for the IRS IT organization.


More Internal Revenue Manual