2.5.1 Systems Development

Manual Transmittal

December 15, 2021

Purpose

(1) This transmits revised IRM 2.5.1, Systems Development, Systems Development.

Material Changes

(1) Manual Transmittal - Signature, Removed Linda K. Gilpin and title, and replaced with the current, Chief Information Officer, Nancy Sieger

(2) Manual Transmittal - Signature, Removed "Application Development (AD)" from the title for Chief Information Officer, Nancy Sieger and included the middle initial "A"

(3) Manual Transmittal - Removed Background section which is no longer the required standard

(4) 2.5.1.1 (1), Included personnel responsible for: engineering, software development, computer programming, analytics, database administration, and system administration; changed the verbiage to eliminate wordiness

(5) 2.5.1.1.2 (1), Included the Government Accountability Office

(6) 2.5.1.1 (5) (a - g), Included stakeholders because of supplementary IRMs:

  1. Computer programmers - government and contractors

  2. Quality Assurance (QA) managers and QA staff - government and contractors

  3. Engineers - government and contractors

  4. Software Developers - government and contractors

  5. System Administrators - government and contractors

  6. Database Administrators - government and contractors

  7. Data Analyst - government and contractors

(7) 2.5.1.1.3 (1) (a-d), Added Information Technology Cybersecurity

(8) 2.5.1.1.3 (7), Changed the role for Director, Customer Service Support

(9) 2.5.1.2 (1), Added the abbreviation (QA) and (CCB)

(10) 2.5.1.2.2.2 (1), Capitalized Sponsor

(11) 2.5.1.3 (3) (e), Changed acronym for Deputy AD Associate CIO from ACIO to (DACIO)

(12) 2.5.1.1.3 (3) (a - f), Included AD responsibilities

(13) 2.5.1.3.2 (3) (g), Included the words “the WR” to complete the phrase

(14) 2.5.1.1.5 (1), Changed Enterprise Program Controls Office sections to reflect the information on the EPMO website

(15) 2.5.1.1.5 (2), Added the mission of the Enterprise Program Controls Office to reflect the information on the EPMO website

(16) 2.5.1.3.1 (1), Added the Change Management purpose

(17) 2.5.1.3.1.1 (1), Included Organizational Change Management (OCM) model

(18) 2.5.1.3.1.1 (2), Included the ADKAR model and five milestones

(19) 2.5.1.3.3 (4), Changed the bullets to alphabets for consistency with paragraph flow

(20) 2.5.1.4.1 (3) (g), Removed the extra word “the”

(21) 2.5.1.4.1.1, Added AD’s thirteen process areas per IRM 2.5.14 guidance

(22) 2.5.1.4.1.1 (b), Included the link for Interim Guidance for IRM 2.5.14 which will be obsoleted once IRM 2.107.1 is published

(23) 2.5.1.4.1.2, Changed the title to include “Role”

(24) 2.5.1.4.1.2 (1), Included the purpose of the Change Control Board

(25) 2.5.1.4.4 (1), Rephrased the sentence by moving “early and efficiently at the end of sentence

(26) 2.5.1.4.9 (1), Removed duplicated word “understanding”

(27) 2.5.1.4.10 (1) (d), Deleted extra word 'to' after must

(28) 2.5.1.4.11 (2), Added the website for Enterprise Services

(29) 2.5.1.4.12 (1), Changed second sentence to read, "The following requirements state what is expected to satisfy this directive:

(30) 2.5.1.4.13 (1), Changed second sentence to read, "The following requirements state what is expected to satisfy this directive:

(31) 2.5.1.4.14 (2), Included the web site link for Human Capital Office for Development and Training, and the document for Career Learning Path

(32) Exhibit 2.5.1-1, Included the following Terms and Definitions:

  • Application, Audit

  • Batch Applications

  • Change Management Program

  • Enterprise Organization Readiness

  • Enterprise Data Standards and Guidelines

  • Generic Application Capability

  • Information Technology Infrastructure Library

  • Procedure

  • Process Improvement,

  • Program Management Office Support Services

  • Program Operations

  • Project: changed the description

  • Sub-application

(33) Exhibit 2.5.1-3, Included the following Supporting Internal Revenue Manuals:

  • IRM 2.110.1, Information Technology, Requirements Engineering, Requirements Engineering Directive IRM 2.120.1 Information Technology, Engineering, Engineering Policy

  • IRM 2.120.5 Information Technology

  • Engineering - Performance Engineering

  • IRM 2.150.2 Information Technology, Configuration Management

  • Configuration Management Process

  • IRM 2.152.3 Information Technology, Data Engineering, Naming Data Element(s)/Object(s)

(34) Exhibit 2.5.1-4, Included Acronyms and Terms

  • CHM - Change Management

  • EDSG -Enterprise Data Standards and Guidelines

  • EPC - Enterprise Program Controls

  • EOR Enterprise Organizational Readiness

  • I&RM - Investment and Risk Management

  • ITIL Information Technology Infrastructure Library

  • PC&I - Program Control and Integration

  • PMOSS - Program Management Office Support Services

  • PSS - Program Support Services

Effect on Other Documents

IRM 2.5.1, dated May 22, 2020 is superseded.

Audience

The audience intended for this transmittal is personnel responsible for engineering, developing, testing, and maintaining Agency software systems identified in the Enterprise Architecture. This engineering, development, and maintenance include that performed by both IT government employees and contractors.

Effective Date

(12-15-2021)


Nancy A. Sieger
Chief Information Officer

Program Scope and Objectives

  1. Purpose: This Internal Revenue Manual (IRM) and the other manuals that constitute IRM 2.5.1 Information Technology, Systems Development establishes the directives, procedures, standards, and other controls intended for the Government to:

    • Ensure Agency software systems are, in an efficient and effective manner, engineered, developed, and maintained

    • Improve the Agency’s capability to engineer, develop, and maintain software systems

    • Improve the Agency’s capability to transition from the current enterprise architecture to the target enterprise architecture

  2. Audience: This IRM 2.5.1 is the baseline guidance for all IRMs under IRM 2.5, and applies to all IRS executives, senior leadership, Information technology (IT) managers at all levels, IT government and contractors. Also included are personnel responsible for: engineering, software development, computer programming, analytics, database administration, system administration, or maintaining Agency software systems identified in the Enterprise Architecture. This engineering, development, and maintenance include services performed by both government employees and contractors.

  3. Policy Owner: Application Development (AD) Chief Information Officer (CIO)

  4. Program Owner: Director, Technical Integration Organization (TIO)

  5. Primary Stakeholders:

    1. IRS IT managers and executives

    2. Computer programmers - government and contractors

    3. Quality Assurance (QA) managers and QA staff - government and contractors

    4. Engineers - government and contractors

    5. Software Developers - government and contractors

    6. System Administrators - government and contractors

    7. Database Administrators - government and contractors

    8. Data Analyst - government and contractors

Background

  1. In response to Government Accountability Office GAO-18-298 Information Technology (IT): IRS Needs to Address Significant Risks to Tax Processing- Investments Performance and Risks, June 2018 report provided to Congressional Committees. IRS IT recognized the importance of continuously improving the performance of IRS Major IT Investments. IT IRS organizations’ Mainframe systems, using legacy programming languages: Common Business Oriented Language (COBOL), Assembler Language Code (ALC), Java programming; etc., IRS Application Development (AD) has established Risk Management strategies and guidance to identify, analyze, mitigate, and monitor risks and issues for system development standards.

Authority

  1. Government Accountability Office

  2. Treasury Inspector General Tax Administration (TIGTA)

  3. Presidential American Technology Council, 2017

  4. Clinger-Cohen Act of 1996

  5. Director of Office of Management and Budget (OMB)

  6. Secretary of the Department of Homeland Security (DHS)

  7. Federal Information Security Modernization Act (FISMA) of 2014

  8. Secretary of Commerce for modernization of Federal IT

  9. 21st Century Integrated Digital Experience Act (IDEA), December 2018

Roles and Responsibilities

  1. Information Technology (IT), Cybersecurity: Cybersecurity manages the IRS IT Security program in accordance with the Federal Information Security Management Act with the goal of delivering effective and professional customer service to business units and support functions within the IRS. These procedures are the following:

    1. Provide valid risk mitigated solutions to security inquisitions.

    2. Ensure all IT security policies and procedures are actively developed, and updated.

    3. Respond to incidents quickly, and effectively in order to eliminate risks/threats.

    4. Provide security advice to IRS constituents, and monitor IRS robust security program for any required modifications or enhancements.

  2. Applications Development (AD): AD is responsible for building, testing, delivering, and maintaining integrated information applications systems, e.g., software solutions, to support modernized systems and production environment to achieve the mission and objectives of the Service. Additionally, AD is responsible for the following:

    1. Works in partnership with customers to improve the quality, and deliver changes to IRS information systems products and services.

    2. A key component of tax processing/filing season activities.

    3. Provides development support for administrative systems related to workforce support, human capital, financial, and facilities.

    4. Establishes and maintains rigorous contract and fiscal management, oversight, quality assurance, and program risk management processes to ensure that strategic plans and priorities are being met.

    5. Maintains the effectiveness and enhance the integration of IRS installed base production systems and infrastructure while modernizing core business systems and infrastructure.

    6. Provides quality assessment and assurance of Enterprise Life Cycle deliverables and processes.

  3. Application Development’s chain of command is the following:

    1. Commissioner: Oversees and provides overall strategic direction for the IRS. The Commissioner’s and Deputy Commissioner’s main focus is for the IRS’s services programs, enforcement, operations support, and organizations. Additionally, the Commissioner’s vision is to enhance services for the nation’s taxpayers, balancing appropriate enforcement of the nation’s tax laws while respecting taxpayers’ rights.

    2. Deputy Commissioner Operation Support (DCOS): Oversees the operations of Agency-Wide Shared Services: Chief Financial Officer, Human Capital Office, Information Technology, Planning Programming and Audit Oversight and Privacy, and Governmental Liaison and Disclosure.

    3. Chief Information Officer (CIO): The CIO leads Information Technology, and advises the Commissioner on Information Technology (IT) matters, manages all IRS Information Technology resources, and is responsible for delivering and maintaining modernized information systems throughout the IRS. Assisting the Chief Technology Officer (CTO) is the Deputy Chief Information Officer for Operations.

    4. Application Development (AD) Associate Chief Information Officer (ACIO): The AD ACIO reports directly to the CIO; oversees and ensures the quality of: building, unit testing, delivering and maintaining integrated enterprise-wide applications systems to support modernized and legacy systems in the production environment to achieve the mission of the Service.

    5. Deputy AD Associate CIO (DACIO): The Deputy AD ACIO reports directly to the AD ACIO, and is responsible for:
      • Leading all strategic priorities to enable the AD Vision, IT Technology Roadmap and the IRS future state
      • Executive planning, and management of the development organization which ensures all filing season programs are developed, tested, and delivered on-time and within budget

  4. AD has the following Domains:

    1. Compliance Domain

    2. Corporate Data Domain

    3. Customer Service Domain

    4. Data Delivery Service (DDS) Domain

    5. Delivery Management Quality Assurance (DMQA) Domain

    6. Identity & Access Management (IAM) Domain

    7. Internal Management Domain

    8. Submission Processing Domain

    9. Technical Integration (TI) Domain

  5. Director, Compliance: Provides executive direction for a wide suite of Compliance domain focused applications and oversee the IT Software Development organization to ensure the quality of production ready applications.

    1. Directs and oversees a unified cross-divisional approach to compliance strategies needing collaboration pertaining for the following:

    • Abusive tax avoidance transactions needing a coordinated response

    • Cross-divisional technical issues

    • Emerging issues

    • Service-wide operational procedures

  6. Director, AD Corporate Data: Directs and oversees the provisioning of authoritative databases, refund identification, notice generation, and reporting.

  7. Director, Customer Service: Directs and oversees Customer Service Support for service and communication with internal and external customers and providing taxpayers with self-service online capabilities.

    1. Customer Service Domain’s applications and systems provide:
      • Tax law assistance
      • Taxpayer education
      • Access to taxpayer account data
      • Maintenance of modernized information systems that meet the customer’s needs for researching, updating, analyzing, and managing taxpayer accounts

    2. Services to internal and external customers are provided through five primary means:
      • Centralized Contact Centers (for telephone, written, and electronic inquiries)
      • Self-service applications (via the telephone and Internet)
      • Field Assistance (for walk-in assistance)
      • Web Services
      • Management of Taxpayer Accounts

  8. Director, Data Delivery Services: Oversees and ensures the quality of data with repeatable processes in a scalable environment. The Enterprise Data Strategy is to transform DDS into a data centric organization dedicated to deliver Data as a Service (DaaS) through:

    • Innovation - new methods, discoveries

    • Renovation - streamline or automate

    • Motivation - incent and enable individuals

  9. Director, Delivery Management & Quality Assurance (DMQA):

    • Executes the mission of DMQA by ensuring AD has a coordinated, cross-domain, and cross-organizational approach to delivering AD systems and software applications

    • Reports to the AD ACIO, and chairs the AD Risk Review Board

    • Chairperson, Configuration Control Board, see IRM 2.5.1.2.2.3

    • Government Sponsor, Configuration Control Board, see IRM 2.5.1.2.2.2

    • For additional information concerning AD roles, see Exhibit 2.5.1-2

  10. Director, Identity & Access Management (IAM) Organization: Provides oversight and direction for continual secure online interaction by verification and establishing an individual's identity before providing access to taxpayer information “identity proofing” while staying compliant within federal security requirements.

  11. Director, Internal Management: Provides oversight for the builds, tests, deliveries, refund identification, notice generation, and reporting.

  12. Director, Submission Processing: Provides oversight to an organization of over 17,000 employees, comprised of: a headquarters staff responsible for developing program policies and procedures, five W&I processing centers, and seven commercially operated lockbox banks. Responsible for the processing of more than 202 million individual and business tax returns through both electronic and paper methods.

  13. Director, Technical Integration: Provides strategic technical organization oversight ensuring applicable guidance, collaboration, and consolidation of technical integration issues and quality assurance for the Applications Development portfolio.

Program Management and Review

  1. The Enterprise Program Management Office (EPMO) is responsible for the delivery of integrated solutions for several of the IRS’s large scaled programs. It plays a key role in establishing change, release plans, and implementing new information system functional capabilities.

  2. The EPMO is the primary partner with the business for programs under their purview and works with IT delivery partners (AD, ES, EOPs and the other ACIO areas) to deliver required capabilities. This structure positions each organization to maintain a strong core function to optimize their operations.

Program Controls

  1. The Enterprise Program Controls (EPC) Office leads the EPMO in Information Technology Enterprise-wide program management functions, and must assist other IT Applications Development (AD) organizations in cross domain support for a variety of program management disciplines. The EPC office is comprised of six sections: Enterprise Organizational Readiness (EOR), Investment and Risk Management (I&RM), Program Control and Integration (PC&I), Pro gram Management Office (PMO) Support Services (PMOSS), Program Operations (PO), and Program Support Services (PSS).

  2. EPMO is essential to the strategic portfolio planning and enterprise portfolio management because it assists with the monitoring and management of IT spending and delivery.

  3. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

Acronyms/Definitions/Terms

  1. For terms and definitions see Exhibit 2.5.1-1

  2. For acronyms see Exhibit 2.5.1-4

Resources

  1. This section describes the Internal Revenue Manual (IRM) that constitutes IRM Part 2 (Information Technology), Chapter 5 (Applications Development). This section also identifies the Internal Revenue Service documents used with this IRM and any other documents associated with this IRM. The controls established in this IRM are based on concepts, principles, and theory expressed in the following references:

    1. IRM 2.5.3, Programming and Source Code Standards

    2. IRM 2.5.4, Document Standards

    3. IRM 2.5.10, Function Point Standards

    4. IRM 2.5.11, Analysis Techniques and Deliverables

    5. IRM 2.5.12, Design Techniques and Deliverables

    6. IRM 2.5.13, Database Design Techniques and Deliverables

    7. IRM 2.5.14, System Development, Quality Assurance

      Note:

      according to Interim Guidance (IG) memo" Control Number: IT-02-1020-0030" IRM 2.5.14 be integrated into IRM 2.107.1 by January 21, 2022, and after publication IRM 2.5.14 will be obsoleted., See for the IG memo link

      .

    8. IRM 10.5.8, Security Privacy and Assurance Privacy and Information Protection, Sensitive But Unclassified (SBU) Data Policy: Protecting SBU in Non-Production Environments

    9. IRM 2.16.1, Enterprise Life Cycle (ELC) - Enterprise Life Cycle details the project life cycles for systems development

    10. IRM 2.100.2, Integrated Process Management (IPM), Integrated Process Management Standardized Process

    11. IRM 2.150.1, Information Technology (IT), Configuration Management, Configuration Management Policy

    12. IRM 2.150.2, IT Configuration and Change Management, Configuration Management

    13. ISO/IEC 20000-1:2011, Information Technology - Service Management - Part 1: System Requirements, 9.2 Change Management

    14. IT Infrastructure Library (ITIL) Service Transition, 2011 Ed., Chapter 4.2 Change Management

  2. Other publications in this Internal Revenue Manual (IRM) are based on decisions, direction, guidance, or recommendations expressed in the following documents:

    1. Capability Maturity Model Integration (CMMI) Version 2.0 for Development, CMMI institute released March 2018, website: https://cmmiinstitute.com

    2. Investment Performance and Risk Tax Processing ((GAO-18-298T), June 2018)

System Development Quality Assurance (QA)

  1. The Quality Assurance (QA) Program Office supports the delivery of high-quality products and services by ensuring projects remain within quality standards as established by the IRS. Currently there are eight process areas and three types of audits currently covered by the AD QA. The process areas are:

    1. Project Planning

    2. Project Monitoring and Control

    3. Configuration Management

    4. Requirements Management

    5. Measurement and Analysis

    6. Software Development

    7. Testing

    8. Supplier Agreement Management

  2. QA audit types are:

    1. Process Audit - Evaluates a process area based on organizational standards and requirements

    2. Work Product Audit - Evaluates work products for conformance to the Enterprise Life Cycle (ELC), Data Item Descriptions (DID) and templates

    3. Release Review Audit - Evaluates a selection of processes used and work products created during a release

Affected Personnel

  1. The controls established in this Internal Revenue Manual (IRM) apply to Agency personnel responsible for engineering, developing, or maintaining Agency software systems identified in the Enterprise Architecture. Agency personnel who contract for development maintenance of these software systems must ensure contracts comply with these controls.

Configuration Controls

  1. A critical aspect of the Change Control process is documenting changes, the more information contained in the documentation, the easier it is complete an: assessment, development, maintenance, and improvement of the process controls established through Internal Revenue Manual (IRM) Part 2 Information Technology, Chapter 5 Systems Development.

  2. The Configuration Controls approves or controls changes to the design, structure, and format of IRMs that constitutes IRM Part 2, Chapter 5.

Configuration Control Board
  1. The Configuration Control Board (CCB) must:

    1. Control the product and service baseline.

    2. Evaluate and approve, or reject proposed changes to the Configuration Item number.

  2. Any new CCBs, subordinate CCBs, or exceptions must obtain approval from the Configuration Management process owner, see IRM 2.150.1 Configuration Management Policy.

Government Sponsor, Configuration Control Board (CCB)
  1. The Configuration Control Board controls the product and service baseline, and concurs on the distribution of all Work Requests resulting in approvals on the CCB SharePoint site.

  2. The Government Sponsor approves, or disapproves Work Requests (WR), or deviations from controls cited under IRM 2.150.2 Configuration Management Process.

Chairperson, Configuration Control Board (CCB)
  1. The Chairperson decides whether a Work Request (WR) will be presented to the Configuration Control Board and designates who will present the WR.

  2. The Configuration Control Board consist of the following:

    1. AD CCBs

    2. Domain CCBs

    3. Branch CCBs

    4. AD, Data Management Quality Assurance (QA)

    5. Enterprise Architecture (EA)

    6. Enterprise Operations, Investment Management and Change Control Board (IMCCB)

Work Requests

  1. Without approval from the Configuration Control Board (CCB), Work Requests or deviations from the process controls established under Internal Revenue Manual (IRM) Part 2 Information Technology, Chapter 5 Applications Development are not authorized.

Quality Assurance (QA) Waivers

  1. QA has established procedures for the waiver justification process. The purpose of the waiver is to uniformly track any project team’s deviation from published standards, and have a documented agreement between the process owner, AD QA and the project team on deviations from accepted standards. For additional information see IRM 2.5.14 IT System Development, Quality Assurance (QA).

Configuration Management (CM)

  1. Configuration Management (CM) is a critical control and discipline process for maintaining information about configuration items required to deliver an IT Service, and ensure the integrity, security, and reliability of information systems.

  2. CM’s purpose is to identify, control, record, report, audit, and verify configuration items and to manage deviations from these controls, IRM 2.150.1 Information Technology, Configuration Management, Configuration Management Policy, establishes the following procedures:

    • Proposing a Change

    • Requesting a Work Request

Change Management (CHM)

  1. The purpose of change management (CHM) is to mitigate risk and impacts during the authorization process to approve any changes being deployed. This process controls the lifecycle of all changes while protecting the production environment during execution of any new changes.

Organizational Change Management (OCM) Model
  1. Organization Change (OCM) is a critical approach to managing the personnel side of change. OCM is critical for determining the origin of the resistance to change which shall keep all stakeholders and sponsors on board with major objectives.

  2. The ADKAR model is an acronym and useful tool that represent five milestones required for achieving successful change that contribute to coping and planning for the process. The ADKAR milestones are the following:

    1. A - Awareness: Demonstrate the need for change: Explain the what and why of the change.

    2. D - Desire: Participate and support the change.

    3. K - Knowledge: Personnel must know how to change by:
      • Obtaining training if necessary
      • Communicating the need and involving people in developing the change
      • Developing and accept the change plans
      • Implementing change plans
      • Performing an assessment of the progress

  3. A - Ability: Consistently implement required skills for change.

  4. R - Reinforcement: Consistently monitor the progress toward reinforce and sustain change. This is prevent reverting back to previous ways.

Proposing a Change

  1. Personnel affected by controls cited under IRM, Part 2 Information Technology, Chapter 5 Applications Development, may propose a change to controls.

  2. The types of process changes are the following:

    1. Emergency Change: A Request-For-Change (RFC) must be submitted for the change to occur as soon as possible as a (P1) or (P2) Incident Management ticket to the Change Analyst.

    2. Standard Change: A Request-For-Change (RFC) must be submitted when an accepted solution from authority was approved in advance. This process pertains to repetitive or reoccurring changes.

    3. Normal Change: A Request-For-Change (RFC) that requires a service change to a service or IT infrastructure. This is not an Emergency or Standard change, and is subject to a full change management review and Change Advisory Board review for authorization/rejection.

  3. To propose a change, the steps are:

    1. Proposer: The proposer must prepare a proposal and submit the proposal to the Change Analyst.

    2. Change Analyst (CA): A Change Analyst is delegated by the Change Coordinator, and must manage/support the: plan, design, and build/test tasks of an RFC within the Change Management Life Cycle.

    3. The CA must also perform the following:

      • The impacted projects must be submitted as comments for the proposal to the responsible Change Analyst.
      • The Change Analyst must review the proposal to determine the impacted projects.
      • The Change Analyst must route the proposal with impacted projects for review.
      • The Change Analyst must package the proposal as a Work Request (WR) and submit the WR to the Coordinator.
      • The Change Analyst’s Frontline Manager must review and authorize the RFC after it is submitted by the initiating Change Analyst.

    4. Change Manager (CM): The Change Manager must support the Technical Authorization and Schedule and Approve Phases by reviewing the submitted Request For Change (RFC). The CM must ensure the RFC follows the correct workflow.

    5. Change Coordinator (CC): The Change Coordinator must coordinate the RFC/WR assessment, planning, and performance of work completed by the technical team.

    6. Change Authority (CA): The Change Authority is the approval group that must accept or reject the RFC/WR during the presentation to the Configuration Control Board (CCB). If the CA accepts the RFC/WR, the Chairperson must present the RFC/WR to the Committee or schedule the Proposer, Analyst, or Coordinator to present the RFC/WR.

    7. Work Request (WR): For WR the following must happen:
      • The Committee must reject or accept the WR
      • If the Committee accepts the WR, the Analyst must package the WR with signatures, then submit the package to CCB SharePoint site.

    8. Change Approver/Change Advisory Board (CAB): The Change Approver or Change Advisory Board (CAB) consist of representatives from all IRS IT organizations/domains that must provide advice on the assessment, prioritization, scheduling of changes, and approval of releases.

  4. For additional information pertaining to Change Management, see IRM 2.125.2 Information Technology, Change Management, Change Management Process Description.

Requesting a Work Request

  1. Personnel affected by controls cited under Internal Revenue Manual (IRM), Part 2 (Information Technology), Chapter 5 (Applications Development) may request a Work Request from these controls. If conformance to a control is impossible, unreasonable, or otherwise not in the best interest of the Agency, then a Work Request from conformance may be requested.

  2. To request a Work Request, the steps are:

    1. The Requestor must prepare a memo requesting the Work Request.

    2. The Requestor must submit the memo to the Configuration Controls.

    3. The Coordinator must review the Work Request and submit the Work Request to the Sponsor, Configuration Control Board (CCB), for approval or denial.

    4. The Government sponsor, CCB must either approve or deny the Work Request.

    5. The Coordinator, within 15 working days, must notify the Requestor of a decision.

  3. When preparing a memo to request a Work Request, at a minimum, the memo must:

    1. Identify the related standards document and, if applicable, the specific standard.

    2. Explain and justify the request for a Work Request.

    3. Identify any pertinent documentation.

    4. Describe an alternative to the waived standard.

    5. Identify a contact.

  4. When notifying the Originator of a decision, at a minimum, the notification must:

    1. State whether the request was approved or denied or state whether additional time is required for a decision.

    2. If additional time is required, then the notification must state the expected date of decision.

    3. State an explanation to the Originator when a request is denied.

Directives

  1. This section establishes directives for applications development. Through internal controls and during the engineering, development, and maintenance of agency software systems, these directives must be satisfied. Exhibit 2.5.1-4, for each directive, lists the IRMs that support the directive.

  2. This IRM establishes the following directives:

    • Assurance of Quality Software

    • Coordinate Change and Maintenance of Applications Configuration Controls

    • Coordinate Change of Applications

    • Curtail Software Defects

    • Define Applications Configuration Controls

    • Engineer Software Products

    • Integrate Engineering and Managerial Activities

    • Manage Requirements

    • Manage Software Changes

    • Manage Software Contracts

    • Plan Applications Change Projects

    • Track and Oversee Applications Change Projects

    • Plan/Define Continuous Process Improvement

    • Manage security controls for system development based on NIST 800-37 Risk Management Framework and NIST 800-53 Revision 4: Security and Privacy Controls

    • Plan/Define Organizational Process Training

Quality Assurance (QA)

  1. The purpose of this directive is to provide management with visibility into the processes being used by organizational units that develop, maintain, and manage software.

  2. The following requirements state what is expected to satisfy this directive:

    1. All activities for Quality Assurance (QA) must be planned.

    2. Quality Assurance must be applied to all Application Change projects.

    3. Software product quality (the conformance of products with standards and requirements) must be objectively validated.

    4. Software service performance (the adherence of services with procedures and requirements) must be objectively verified.

    5. Organizational units affected by QA activities must be informed of these activities and the results.

    6. Noncompliance issues unresolved among organizational units must be organizationally elevated and resolved.

  3. The Delivery Management and Quality Assurance (DMQA) manager must request and initiate an appraisal of how AD is performing their process against the referenced process improvement model.

Audit Process Control
  1. The Quality Assurance Program conducts audits for organizational process areas as outlined in the AD Process Framework located in the IT Process List on the Information Technology Process Asset List (IT PAL). AD Quality Assurance is responsible for thirteen process areas, and three types of audits for process control:

    1. The thirteen process areas are:
      Project Planning (PP)
      Project Monitoring and Control (CM)
      Configuration Management (PCM)
      Quality Assurance (QA)
      Requirements Engineering (RQEN)
      Risk Management (RSKM)
      Process Management (PRM)
      Privacy (PRIV)
      Section 508 (508)
      Security (SEC)
      Software Development (SWDEV)
      Supplier Agreement Management (SM)
      Testing (TEST)

    2. The three audit process controls are:

    • Process Area Audit

    • Work Product Audit

    • Process Owner Audit

    • For additional information review, IRM 2.5.14 System Development, Quality Assurance

      Note:

      According to Interim Guidance Control Number: IT-02-1020-0030 this IRM will be integrated into IRM 2.107.1, and after publication by January 31, 2022 IRM 2.5.14 will be obsoleted.

  2. The final Audit Findings report is issued and stored in the QA repository, and when audit findings need corrective action, a Corrective Action plan is requested from the auditor as a part of the Audit Findings report.

  3. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡

Change Control Board (CCB) and Roles
  1. The purpose of Change Control Board (CCB) is a team of stakeholders responsible for evaluating, approving or disapproving proposed changes to a system, prioritizing the incorporation of approved changes, and scheduling the change for forthcoming releases.

  2. The Chief, IT Enterprise Operations, Demand Management & Project Governance (DMPG) Change Advisory Board (CAB) Application Development (AD), QA and Senior AD QA Management Analyst serve as the QA CCB and manage Change Control procedures when new QA documents are developed or Changes Request (CR) have been received:

    1. The Chief, AD QA and the Senior AD QA ensure the following tasks are accomplished:
      • Accurate sequential numbers are assigned to each CR received, and the request is recorded in the QA CR log
      • All updates to the AD QA database with results from the audit or other record of QA audit activities
      • Change Requests are forwarded to the Change Control Board for disposition
      • AD QA CCB meet monthly, and review any Change Request (CR) received, in accordance with the AD QA Change Control Procedures.

    2. For Process Asset Integration Group assets, the approval process starts with the CCB, but must be approved by the AD Program Management Office (PMO) and Associate CIO.

    3. For additional information see, IRM 2.5.14 System Development, Quality Assurance.

Coordinate Change and Maintenance of System Change Control

  1. The IT Enterprise Operations, Demand Management & Project Governance (DMPG) Change Advisory Board (CAB) is a community of IT executives and IT professionals that advise and collaborate with the Application Development domain for the assessment, prioritization, scheduling of changes, and the approval of releases.

  2. The purpose of this directive is to establish organizational responsibility for activities that improve the Agency’s capability to develop systems and software applications. The following requirements state what is expected to satisfy this directive:

    1. System Change and improvement activities must be coordinated across the organization.

    2. Strengths and weaknesses of the Change processes used must be identified relative to the standard processes.

    3. Organization-level Change processes, and improvement activities must be planned.

Coordinate Change of Software

  1. The purpose of this directive is to establish a means for the system development Change Management processes to participate with the other Change groups so that the project is better able to satisfy the customer’s needs. The Demand Management & Project Governance (DMPG) is responsible for the development, implementation, and maintenance of this process. The following requirements state what is expected to satisfy this directive:

    1. The customer’s business requirements must be agreed to and signed by all affected organizations.

    2. Commitments among the Change organizations must be agreed to by affected organizations.

    3. Development organizations must identify, track, and resolve issues.

Curtail Software Defects

  1. The purpose of this directive is to remove defects from software early and efficiently. The following requirements state what is expected to satisfy this directive:

    1. Planning and coordination of requirements.

    2. Peer review meetings must be planned.

    3. Defects in software products must be identified by total number of major and minor defects found by all peer reviewers, and Removed.

    4. Rework must be performed to resolve issues found

    5. A follow-up peer review meeting must be performed for reworked requirements artifact

    6. Exit Criteria - All defects and issues have been identified, corrected, and the product is accepted.

Define System Configuration Controls

  1. The purpose of this directive is to develop and maintain a usable set of system Change process assets and controls that improve process performance across the organization and that provide a basis for cumulative, long-term benefits to the organization. The following requirements state what is expected to satisfy this directive:

    1. A standard Change and maintenance process for the organization must be developed and maintained.

    2. Information about the organization’s use of standard processes must be collected, organized, reviewed, and shared.

Engineer Software Products

  1. The purpose of this directive is to consistently perform a well-defined engineering process that integrates all software engineering activities, effectively and efficiently, to produce correct, consistent software products. The following paragraphs state what is required to satisfy this directive:

    1. Software engineering tasks/activities must be defined, integrated, and consistently performed to produce software.

    2. Software products must be kept consistent.

Integrate Engineering and Managerial Activities

  1. The purpose of this directive is to integrate the software engineering and management activities into a coherent, defined process that is tailored from the organization’s Configuration Controls. The following requirements state what is expected to satisfy this directive:

    1. Project plans must be tailored from the Agency’s standard Change processes.

    2. Projects must be planned and managed according to the Agency’s standard Change processes.

Improve Processes and Maintain Process Assets

  1. The purpose of this directive is to receive, evaluate, review and implement new improved, or enhanced processes then implement best practices. The following requirements state what is expected to satisfy this directive for Continuous Process Improvement (CPI):

    1. Establish the framework for organizations to make incremental process improvements.

    2. Establish and maintain a set of organizational process assets.

    3. Plan, implement, and communicate improvements.

    4. Coordinate and deploy Process Change and improvement activities across the organization.

    5. Develop new and updated processes and process assets.

Manage Requirements

  1. The purpose of this directive is to establish a common understanding of the requirements allocated to the software) between an organizational unit that is acquiring software and an organizational unit that is developing or maintaining the software. The following requirements state what is expected to satisfy this directive:

    1. System requirements allocated to software must be controlled to establish a baseline for software engineering and management.

    2. When allocated requirements are changed, the plans, products, and activities associated with the software must be accordingly changed.

Manage Software Configurations

  1. The purpose of this directive is to establish and maintain the integrity of the product, throughout the life of the corporate software product. The following requirements state what is expected to satisfy this directive:

    1. Software configurations management activities must be planned.

    2. Corporate software products, identified as software configuration items, must be cataloged, controlled, and inventoried.

    3. Access to, changes to, and distribution of configuration items must be controlled.

    4. Organizational units involved in software configuration management activities must be informed of the status and content of software baselines.

Manage Software Contracts

  1. The purpose of this directive is to select qualified software contractors and effectively manage them. The following requirements state what is expected to satisfy this directive:

    1. Documented standards and procedures must be used in selecting software subcontractors and managing the subcontract.

    2. Project managers and subcontractors must agree to their commitments to each other.

    3. Project managers and subcontractors must maintain ongoing communication.

    4. Project managers must track contractor’s actual results and performance against commitments.

  2. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡≡ ≡ ≡

Plan Applications Development Projects

  1. The purpose of this directive is to establish reasonable plans for managing Change projects and performing engineering tasks. The following requirements state what is expected to satisfy this directive:

    1. Estimates must be documented and used in project planning and tracking.

    2. Project activities and commitments must be planned and documented.

    3. Project commitments must be negotiated between all managers involved in a project and the results of this negotiation must be documented.

Track and Oversee Applications Development Projects

  1. The purpose of this directive is to provide adequate visibility into the actual development progress so that management can take effective actions when the project’s performance deviates significantly from the plan (project plan or applications Change plan). The following requirements state what is expected to satisfy this directive:

    1. Actual results and performance must be tracked against the project plan.

    2. When actual results and performance significantly deviate from the plan, corrective actions must be taken and managed to closure.

    3. Changes to project commitments must be agreed to by managers in affected organizational units.

Define/Plan Organizational Process Training

  1. The purpose of this directive is to develop the skills and knowledge of employees to perform their role effectively and efficiently. The following requirements state what is expected to satisfy this directive:

    1. Training activities are planned.

    2. Identify training needed by the organization.

    3. Obtain and provide training to address those needs.

    4. Establish and maintain training records.

    5. Assess training effectiveness.

  2. ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡ ≡≡ ≡ ≡

Terms and Definitions

Terms Descriptions
Agency Software System A software system developed by or for an agency.
Application
  1. A 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.

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

Audit An independent examination of deliverables, products, or services performed to assess compliance with established policies, procedures, standards, processes or other controls.
Batch Applications Manage data, and generate reports, etc., as part of a business process.
Capability Maturity Model A description of the stages through which an organization or organizational unit evolves as it defines, implements, measures, controls, and improves its Change processes. By facilitating the determination of current capabilities and the identification of issues most critical to product quality and service performance, this model provides a guide for selecting improvement strategies.
CCB SharePoint A SharePoint site that displays a change in Configuration Controls. The bulletin describes the change, justifies the change, states the benefits of implementing the change, identifies the affected Internal Revenue Manual, lists the organizational units/personnel that are affected and targeted for IRM document clearance, and identifies a contact for responses to the change.
Change Management Program The objective of the ChM program is to create and deploy a standard ITIL Change Management process for all of IT, supported by an integrated change management system.
Continuous Improvement Sometimes called continual improvement. The ongoing improvement of products, services, or processes through incremental and breakthrough improvements.
Continuous Process Improvement Provides a framework for organizations to make incremental process improvements, even in those processes that are considered to be in good operating condition. It is based on the philosophy that organizations can always make improvements.
Control A statement published to either
1) Determine or influence decisions
2) Establish limits, alternatives, and guidelines for personnel who exercise discretion in applying their authority or fulfilling their duties and responsibilities.
Customer A person or organizational unit that is responsible for accepting a product or service and for authorizing payment to the provider.
Configuration Controls Controls used to influence or determine decisions regarding the engineering, development, or maintenance of systems. In a managerial context, a Configuration Controls may constitute a policy, directive, standard, or procedure. In a technical context, a Configuration Controls may address a deliverable, method, process, technique, task, or tool.
Directive A control that expresses executive commitment, direction, or leadership.
Enterprise Organization Readiness Enterprise Organizational Readiness (EOR) ensures the preparedness of organizations through a proven framework to identify and drive the resolution of gaps in the focus areas of People, Process, Technology and Financial readiness with a joint partnership between IT Delivery Partners and Business stakeholders.
Enterprise Data Standards and Guidelines IRS standards and guidelines for the development and modification of the names, definitions, and other metadata for classes, attributes, and data models.
End User When a product or service is deployed in its operational environment, an end user refers to the person or organizational unit that will use the product or service for its intended operational use.
Findings The conclusions of an assessment, evaluation, audit, or review that identify issues, problems, or opportunities within the area of investigation.
Focus group A group, usually of 8 to 10 persons, that is invited to discuss an existing or planned product, service or process.
Generic Application Functionality This 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 Application Capability Provided by COTS applications, whereas IRS-specific capabilities generally involve custom-developed applications.
Guideline A control that is not monitored for compliance, or compliance is not mandatory.
Information Technology Infrastructure Library A set of detailed practices for Information Technology (IT) Service management (ITSM) that focuses on aligning IT services with business objectives.
Method A set of criteria and rules that establishes a consistent, predictable, or repeatable way to perform a task or produce a result.
Methodology A synthesis of controls, methods, plans, or principles that constitutes an approach for accomplishing something.
Organization An organizational unit that comprises other organizational units.
Organizational Unit A group of people acknowledged as a unit within an organization.
Peer Review A review of a deliverable/product performed by peers of the producers of the deliverable/product and performed to identify defects and improvements.
Procedure A control used and enforced to establish uniform performance of some activity or service.
Process Improvement An application of the plan-do-study-act (PDSA) philosophy to processes to produce positive improvement and better meet the needs and expectations of customers.
Process Improvement A structured environment often made up of cross functional members who work together to improve a process or processes.
Program
  • A group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually.

  • Programs may include elements of related work outside the scope of the discrete projects in the program.

  • A collection of related projects and the infrastructure that supports them, including objectives, methods, activities, plans, and success measures.

Program Management Office Support Services Program Management Office Support Services (PMOSS) supports new and existing IT programs by providing program management best practices through leadership, individualized guidance, and easily accessible tools.
Program Operations Program Operations (PO) is responsible for financial management and acquisition support to the Enterprise Program Management Office (EPMO) and the individual programs and projects that the EPMO provides sponsorship.
Program Support Services Program Support Services (PSS) provides employee engagement development and support, SharePoint solutions and workforce planning efforts for the EPMO.
Project A managed set of interrelated resources which delivers one or more products to a customer or end user. A group of tasks to accomplish a specific objective, with a beginning and ending date; and typically operates according to a plan. This plan is frequently documented, specifies the deliverables, resources, required funds, tasks, and schedule of work.
Project Manager A role assigned to a person who is expected to manage a project and manage according to a budget, schedule, defined scope, and documented plan.
Software Application A software product applied in some discipline or field (e.g., accounting, purchasing, project management) to accomplish work.
Software Product The complete set or any of the individual items of the set, of computer programs, procedures, and associated documentation and data designated for delivery to a customer or end user.
Software System A collection of software components organized to accomplish a function
Standard A control that specifies a mandatory characteristic for some product or other result, and is enforced to prescribe a uniform quality for a product or other result
Sub-application
  1. A part of a larger application (please see definition for application above):

    • Functionality supports business processes

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

    • This can reference other sub-applications to any depth

Sub-project A component of a larger project.
System A collection of components organized to accomplish a specific function or set of functions.
System Requirement A condition or capability that a system or system component must meet
Tailor To modify a process, standard, or procedure.
Work Product All products and deliverables including the standards/procedures used to produce them.

Roles By Organizational Unit

This exhibit identifies the organizational units assigned to the roles established through this IRM. Where a role is assigned to an organizational unit, the assignment means the role is assigned to the manager of the unit, or person delegated by the manager.

Role Organizational Unit
Change Control Board Director, Delivery Management and Quality Assurance
    OS:IT:AD:DMQA
Configuration Control Board Director, Corporate Data
    OS:CIO:AD:CP
  Director, Compliance Systems
    OS:CIO:AD:C
  Director, Internal Management Systems
    OS:CIO:AD:IM
  Director, Submission Processing
    OS:CIO:AD:SP
  Director, Customer Service
    OS:CIO:AD:CS
Sponsor, Configuration Control Board Director, Technical Integration Organization
    OS:CIO:TIO
Chairperson, Configuration Control Board Application Development
    OS:CIO:AD

Directives and Supporting Internal Revenue Manuals

Directive IRM that supports Directive
Establishes standards and guidelines for development of maintainable, portable, reliable software applications IRM 2.5.3, System Development Programming and Source Code Standards
Guidelines on preparation of Enterprise Life Cycle documents that are the deliverable IRM 2.5.4 , Document Standards
Establishes standards for conducting the QA audit process within Application Development (AD) IRM 2.5.14 , Quality Assurance
Establishes all components and infrastructure of the IRS EA IRM 2.15.1, Enterprise Architecture (EA), EA Overview
Provides a standard for IRS ELC framework for managing, governing and supporting system tactics, architecture, IT security, and engineering IRM 2.16.1 , Enterprise Life Cycle (ELC) Guidance
Requirements Development and Requirements Management process areas IRM 2.110.1, Information Technology, Requirements Engineering, Requirements Engineering Directive
Standard for planning and performing development and integration of IT based systems within the IRS. IRM 2.120.1, Information Technology, Engineering, Engineering Policy
Standard Best practice for creating a set of procedures to obtain key processes for business objectives IRM 2.120.2, IT Engineering, Technical Solution Process
Establishes standards for Project Performance requirements IRM 2.120.5, Information Technology, Engineering - Performance Engineering
Establishes standards for verification and validation activities for all phases of the testing life cycle. IRM 2.127.1 Information Technology, Testing Standards and Procedures Testing Policy and IRM 2.127.2 , Testing Standards and Procedures
Define System Development Configuration Controls IRM 2.150.1, Information Technology, Configuration Management Policy
Establishes standards for the Change Management Process IRM 2.150.2 , Information Technology, Configuration Management, Configuration Management Process
Establishes standards for creating data names and eliminating data redundancies IRM 2.152.3, Information Technology, Data Engineering, Naming Data Element(s)/Object(s)

Acronyms and Definitions

Acronym Definition
ACIO Assistant Chief Information Officer
AD Application Development
ADKAR Aware, Desire, Knowledge, Ability, Reinforcement
CCB Change Control Board
CCB Configuration Control Board
CIO Chief Information Officer
ChM Change Management
CMM Capability Maturity Model
CR Change Request
CMMI Capability Maturity Model Integration.
CPI Continuous Process Improvement
DCOS Deputy Commissioner for Operations Support
EDSG Enterprise Data Standards and Guidelines
ELC Enterprise Life Cycle
EPC Enterprise Program Controls
EPMO Enterprise Program Management Office
EOR Enterprise Organizational Readiness
IRM Internal Revenue Manual
I&RM Investment and Risk Management
IRSD Internal Revenue Service Document.
ITIL Information Technology Infrastructure Library
PC&I Program Control and Integration
PDCA Plan-Do-Check-Act
PMOSS Program Management Office Support Services
PSS Program Support Services
QA Quality Assurance
QC Quality Control
WR Work Request.