Internal Revenue Manual
IRM 2.22.1 — Unified Work Request (UWR) Process
Part 2. Information Technology
Chapter 22. Requirements and Demand Management Section 1. Unified Work Request (UWR) Process 2.22.1 Unified Work Request (UWR) Process Manual Transmittal February 23, 2024 Purpose (1) This transmits revised IRM 2.22.1, Business Planning and Risk Management (BPRM), Unified Work Request (UWR) Process. Material Changes (1) IRM 2.22.1 Manual Transmittal - Updated IRS CIO from Kaschit Pandya to Rajiv Uppal. (2) IRM 2.22.1.10 (11) Work Request Standards - Revised paragraph to reflect 30 days for the IT resource supplier to record their work request actual costs and resources after the UWR is implemented and/or delivered. Effect on Other Documents IRM 2.22.1, dated February 5 2024, is superseded. Audience This IRM applies to all Internal Revenue Service (IRS) employees Treasury organizations and other official affiliates requesting or providing Information Technology (IT) products and services from IT. Effective Date (02-23-2024) Rajiv Uppal Chief Information Officer
Program, Scope and Objectives
2.22.1.1 (02-23-2024) Program, Scope and Objectives Purpose: This IRM defines the Unified Work Request (UWR) process and the policy for submitting and responding to work requests. Audience: This IRM applies to all Internal Revenue Service (IRS) employees, Treasury organizations and other official affiliates requesting or providing Information Technology (IT) products and services from IT. Policy Owner: The Chief Information Officer (CIO) is responsible for overseeing all aspects of our systems that operate the nation's tax infrastructure. Program Owner: The Business Planning & Risk Management (BPRM) Division of Associate Chief Information Officer (ACIO) Strategy and Planning maintains the Project and Portfolio Management (PPM) application, which includes the PPM-Work Request Management System (WRMS) (PPM-WRMS) module, and provides training to facilitate and support the UWR process. All requirements for designated IT products and services, beyond the scope of the break/fix IT tickets and service requests via IRS Service Central tickets, shall be documented through the UWR process on a work request via PPM-WRMS. All work requests will be processed using the established UWR process standards and PPM-WRMS module. All persons needing access to PPM-WRMS must first be registered for the module based on their role in the UWR process. Registration must be done in compliance with the Business Entitlement Access Request System (BEARS) application. Primary Stakeholders: All Internal Revenue Service (IRS) employees, Treasury organizations and other official affiliates requesting or providing Information Technology (IT) products and services from IT. Scope: The provisions of this IRM apply to the UWR process from the initial work request through final disposition. This IRM addresses standards and policies for the preparation, submission, approval, coordination and control of work request documents and responses. Program Goals: The IRM provides the fundamental knowledge and procedural guidance for employees who submit or respond to requests for any Information Technology (IT) products or services. By following the processes and procedures provided by this IRM, employees will better understand the essentials of the UWR process.
Background
2.22.1.1.1 (02-05-2024) Background Information Technology (IT) is committed to increasing customer satisfaction through effective registration and efficient response to demand for IT products and services. IT products and services are managed through the UWR process to register demand for IT resources. The UWR process includes registering demand for IT products and services that follow an Agile Development Methodology. The process uses work requests to represent a contract between IT and our business and functional operating divisions (BODs/FODs). The UWR process focuses on collecting requests for IT products and services from IT into a single flexible system using a common set of processes and procedures. The Business Planning & Risk Management (BPRM) Division is responsible for the oversight of the IRS IT demand management program and the UWR process. The primary goal of the program is to register all demand for IT products and services and provide transparency for data driven decision making for resource commitments. This includes collecting all related business requirements to enable IT suppliers to properly review, assign, analyze, and respond (approve/deny) to the request. The IT supplier resource will also provide the cost and schedule for the implementation and/or delivery of any agreed upon IT products or services. PPM-WRMS provides a predefined selection of workflows for different work request types and supplier-based impact cost analysis (ICA) workflows. This design allows end-to-end management of registered demand from the initial request through IT evaluation, analysis, disposition, and work planning. This design also includes the Agile Intake Form for capturing IT demand from customers that follow the Agile Development Methodology. The UWR process is supported by PPM-WRMS by providing a common framework to manage the end-to-end life cycle of work requests submitted to IT for products and services such as changes to IRS computer applications, systems, infrastructure, sustaining operations, enhancements, etc. A work request, together with the formal response/disposition, provides the IRS with a vehicle for formal communications and commitments regarding IT demand management between requestor organizations and IT.
Authority
2.22.1.1.2 (02-05-2024) Authority Capital Planning and Investment Control (CPIC) Clinger Cohen Act OMB Circular A-130 Federal IT Acquisition Reform Act (FITARA) of 2014 Taxpayer First Act Chief Financial Officers Act Government Performance and Results Act
Responsibilities
2.22.1.1.3 (02-05-2024) Responsibilities The Director, Business Planning and Risk Management (BPRM), is the program director responsible for UWR program administration. The Director, BPRM designates oversight responsibility for the UWR program, including IRMs.
Program Management and Review
2.22.1.1.4 (02-05-2024) Program Management and Review PPM-WRMS effectively and accurately provides IT with requirements and demand management information for all actions and initiatives associated with Information Technology provisioning to the IRS: Through processes of continuous improvement and renders data reporting for strategic and tactical action points. Set and administer Unified Work Request (UWR) policy and procedure. Promote the use of common UWR processes incorporating customer requirements in order to make the process more efficient. PPM-WRMS provides the ability to generate a variety of standard reports, lists, and views which allows the data to be used to: Provide information to aid the decision-making process and help prioritize work. Help track process efficiencies, work volumes, and prioritized activities. Provide trending and other management metrics. The PPM-WRMS Dashboard provides real time visibility of functional role-based information to aid the decision-making process and help prioritize work. PPM-WRMS uses Business Intelligence and Tableau to support enterprise-level reporting.
Program Controls
2.22.1.1.5 (02-05-2024) Program Controls This framework uses the IRS Internal Management Documents System to establish controls. This IRM section constitutes one of the controls.
Terms and Acronyms
2.22.1.1.6 (02-05-2024) Terms and Acronyms Please refer to Exhibit 2.22.1-2 Terms and Acronyms for additional information.
Related Resources
2.22.1.1.7 (02-05-2024) Related Resources Supplemental information related to the UWR process can be found on the BPRM WRMS website. The UWR process is supported by PPM-WRMS by providing a common framework to manage the end-to-end life cycle of work requests submitted to IT for products and services such as changes to IRS computer applications, systems, infrastructure, sustaining operations, enhancements, etc. A work request, together with the formal response/disposition, provides the IRS with a vehicle for formal communications and commitments regarding IT demand management between Requestor organizations and IT. This IRM is available through the BPRM WRMS website and the IRS IRM website.
Distribution of the UWR IRM
2.22.1.1.8 (12-27-2019) Distribution of the UWR IRM This IRM is available through the BPRM WRMS website and the IRS IRM website.
Overview of the UWR Process
2.22.1.2 (02-05-2024) Overview of the UWR Process The IRS BODs or FODs, also known as the requestor, determine a need for IT products or services and develop a work request to begin the communication of this request. A work request is a formal notification to an IT supplier organization(s) that a requestor organization has a business need for IT products or services. The work request documents the IT services or products required and includes changes to current, planned systems/applications or IRS infrastructure. Work requests include, but are not limited to: Designing, developing, testing, implementing new or enhanced systems Maintenance of Current Production Environment (CPE) systems Providing systems engineering analysis Hardware/infrastructure changes for IRS systems Commercial Off-the-Shelf (COTS) software products/support System testing Other IT services beyond the scope of tickets for break/fix and IRS Service Central requests for service Software/Infrastructure changes for IRS systems All work requests require a business priority, except for requests for demand that follows the Agile Development Methodology. (Please see IRM 2.22.1.6.6.1 Agile Enterprise Intake (AEI) Process for additional guidance. High and Critical requests will require additional justification with a business impact and value summary. In addition, a setting of High and/or Critical is required when a work request is submitted late as outlined in the annual submission deadline memorandum. The WR Submission Deadline Memorandum and Submission Deadline Chart can be located at the BPRM WRMS website. Low - Requests that have been submitted but are lower in priority for fulfillment Normal - Requests submitted timely for consideration in the designated timeframes. High - Requesting organization is requiring implementation in less than 90 days for Enhancement and Legislative WRs or 90 days for O&M and Rust WRs or work request is determined to be a late submission as outlined in the annual submission guideline memo. Critical - Requesting organization has identified the request as a critical business need and can demonstrate in the justification the value and impact if the request is not satisfied (examples include legislative mandated requests with a directed implementation date). Work requests resulting in new legislation and business initiatives may impact IRS financial systems and related processes. For example, these systems and processes include such areas as tax revenue receipts, refunds, frozen credits, unpaid tax assessments, travel, property, and payroll. The requestor must initiate coordination with the CFO organization so they can begin to assess the potential impact to the financial systems. Please see the Additional Guidance on Program Initiatives and Changes Affecting the IRS Financial Systems memo and the Financial System Flagged Projects in WRMS SOP for additional guidance. Customers that follow the Agile Development Methodology will use the Agile Intake Form to capture their IT Demand. (See the AEI process for additional guidance). All work requests, with the exception of the Agile Intake Form, submitted during the Executive Review Board (ERB) Filing Season Review period will be routed through the Business System Planning (BSP) and ERB approval processes prior to submission to IT. The ERB Filing Season Review period is established annually and announced prior to the start of the ERB. (Please access the WRMS Library for the current ERB Filing Season Review period.) Any work requests submitted with a Requested Implementation Date (RID) and the Requesting Organization Approval date between the ERB Filing Season dates will be routed through the BSP and ERB approval processes prior to submission to IT. The BSP offices represent the various BOD/FODs and serve as business liaisons for their respective organizations. The BSP offices are responsible for initially reviewing, prioritizing and approving work being submitted to IT. Work requests approved by the BSP offices are submitted to the ERB for approval prior to submission to IT. Note: Although IT does not have a formal BSP office, it can be selected and the request will be routed to the appropriate BSP coordinator. The ERB office reviews and evaluates work requests tagged for ERB approval (which has been approved by the BSP office) and schedules the request for formal ERB Reviews. An IT organization is considered a requestor organization when requesting support/resources from another IT organization. In addition to the systemic notifications generated during the processing of a work request, constant communication, and coordination with the requestor of each work request during processing within IT is required. As a service, IT representatives will, at a minimum, contact the requestor whenever a work request response or delivery date is changed. Adherence to this policy to gain concurrence on date changes is essential to building and maintaining customer confidence in IT's ability to provide quality end-to-end service. Extending a scheduled response or delivery date may cause a negative impact on the requesting organization and increase escalated work requests impeding planning and efficiency. Pre-coordination is the mandatory process to establish an integrated, cross-functional perspective of the WR throughout IT and to ensure that the WR is ready for formal submission to IT. Pre-coordination has several objectives: Ensures IT understands the requesting organization's need Confirms that the WR requirements are complete and accurate Allows IT to recommend an alternative approach, as appropriate Identifies IRS systems affected by the request Obtains a preliminary assessment of the IT organization resources needed to complete the WR Identifies the IT investment and project funds for the request At the completion of the pre-coordination process, the requesting organization and IT will decide whether to proceed with formal submission of the WR in PPM-WRMS. If the decision is to proceed, the WR will continue its route through the requesting organization. If the decision is to not proceed, the WR will be cancelled. There are key advantages to pre-coordination: Encourages cross-functional collaboration Reduces cost Increases quality Reduces technical debt Increases productivity by stopping mistakes early
UWR Process Roles and Responsibilities
2.22.1.3 (12-27-2019) UWR Process Roles and Responsibilities The following describes the key roles and functional responsibilities in the UWR process supported by PPM-WRMS.
Requestor Organization (Business (BOD) or Functional Operating Divisions (FOD) including IT)
2.22.1.3.1 (02-05-2024) Requestor Organization (Business (BOD) or Functional Operating Divisions (FOD) including IT) Any BOD or FOD requesting IT support and resources, including IT itself, is a requestor organization. The requestor organization has the following responsibilities: Identify specific business justification and requirements to register demand for IT resources. Coordinate with the BSP staff to prioritize the business needs per its own organizational specific procedures, as appropriate. (This only applies to those organizations that have a BSP staff.) Designate organizational level additional reviewers (if needed) and approvers for each assigned work request. Document the IT contact, as appropriate, that may be a current or former supplier on a similar type of request for a specific product or service. Contact the Work Request Support Office (WRSO) Office in BPRM for assistance, if a contact cannot be identified. Establish and maintain internal policies and procedures for the review and clearance of work request documents in accordance with this IRM. Respond to work determination questions and information requested for work request type selected.
Requestor
2.22.1.3.2 (02-05-2024) Requestor The requestor creates and submits the work request on behalf of the requesting organization. In most cases, the requestor contact and submitter are the same, but if appropriate can be separate contacts. The requestor contact is a subject matter expert for the requestor organization's business needs and requirements described in the work request submitted. The requestor is responsible for: (1) Creating the work request. The requestor has the ability to open a request on behalf of another requestor contact or can remain as the requestor contact. (2) Following internal work request policies and procedures established by the requestor organization in order to coordinate the work request for an organization. (3) Using the work request Pre-Submission guide at the BPRM WRMS website to prepare a work request. (4) Collecting the information needed to prepare the work request. The requestor consults with other analysts or IT, as appropriate. (5) Assisting the requestor contact, if different from submitter, in defining requirements for an organization. The requestor is responsible for ensuring all high-level requirements/business needs, designs, processes, business rule sets, or business rules, are reflected in the work request prior to submission. (6) Initiating, documenting, and ensuring completion of pre-coordination between the requesting organization and potentially impacted IT suppliers. (7) Using PPM-WRMS to submit the work request. (8) Submitting AEI Request forms into PPM-WRMS. (9) Requesting products or services from the IT organization by selecting a work request type for the product/service needed and completing all required information to ensure information in the work request document is complete. (10) Ensuring all requirements and business needs directly match up with the work request (WR) type that is being submitted. (i.e. Legislative WRs should only include requirements that are needed to implement legislation; Enhancement WRs should only include requirements that are needed to implement an enhancement work request.) BPRM reserves the right to return any WR if it is determined that requirements in a single WR relate to more than one work request type. (11) Designating additional reviewers on the work request, as needed, in accordance with organizational policies and procedures and set the number of calendar days allocated before the request is sent to the requestor allowing them to review for feedback, update the work request and forward it for approval. (12) Designating approver(s) on each work request in compliance with requesting organization standards. (13) Completing all work request determination questions and attaching documents, files, high-level requirements/business needs, designs, processes, business rule sets, or business rules from a BPRM requirements repository, and/or references needed to support the work request requirements. (14) Identifying the IT points of contacts. (15) Identifying impacted organizations. (16) Serving as a point-of-contact or subject matter expert (SME) regarding an organization's business requirements. (17) Identifying the business requirements, priority and justification (that is in alignment with your organizational priorities), for IT products and services. (18) Gathering and documenting the business requirements, justification and needs. (19) Determining a requested implementation/delivery date for a product or service to be used by IT suppliers to assess during analysis. (20) Ensuring information entered on the work request is complete and accurate. (21) Serving as the requestor organization's primary representative in coordination with the IT primary coordinator and supplier contacts. (22) Consolidating information and requirements to submit to the IT organization for evaluation. (23) Obtaining late submission documentation and attaching it to the work request, if required. (24) Setting the priority of the work request in PPM-WRMS and providing documentation, as required. (25) Responding to any requests for more information on the request throughout the process. (26) Withdrawing or cancelling a request, if appropriate, as outlined in the WRMS User Guide. (27) Escalating a denied request or any issue relating to the scheduled implementation date as proposed by the supplier. (28) Submitting an IRS Service Central ticket, as needed, to obtain PPM-WRMS or UWR process support from BPRM via calling 1-866-7HELP4U (1-866-743-5748) or TTY 1.866.HELP4U6 (1-866-435-7486) or visiting IRS Service Central website.
Additional Requestor Reviewer(s)
2.22.1.3.3 (02-05-2024) Additional Requestor Reviewer(s) The requestor contact may designate (as needed) one or more additional impacted organizations and contacts as subject matter experts to ensure that all relevant high-level requirements/business needs, designs, processes, business rule sets, or business rules are identified prior to submission. The designated additional reviewers will be notified via e-mail to review the request before it is submitted. The requestor contact initiates the process and is responsible for the following: Selecting the reviewers and the number of calendar days allowed for the reviewers to add input and notes to the request. (Once the time limit has been met the request will automatically move back to the requestor for updates, as appropriate.). Monitoring the progress of the request. The additional requestor reviewer has the following responsibilities: Review and comment on the work request within the number of calendar days identified by the requestor. Contact the requestor contact for any issues, questions or additional coordination.
Request Approver
2.22.1.3.4 (02-05-2024) Request Approver The request approver is the central requestor organizational point of contact for the UWR process. request approvers are designated personnel in the requesting organization. The request approver is the individual designated as having the authority to approve a work request for a particular requesting organization. The request approver is responsible for the following: Reviewing each work request document for completeness, such as the work request determination questions and ensuring that responses, high-level requirements/business needs, designs, processes, business rule sets, or business rules are included with any required late submission documentation, if needed. Returning incomplete work request documents to the requestor contact/submitter for correction and/or more information, as needed. Verifying completeness and adherence to both the requestor organization's internal work request procedures and to the requirements of the UWR IRM. Serving as the liaison between the designated requestor contact, primary coordinator and IT supplier(s). This individual works in the organization that is requesting IT services. This individual also serves as a point of contact for coordination of the work request until the work is completed. Participating in the escalation processes as needed through the UWR process. Assigning additional approvers in the work request to ensure each requestor organization's procedures can be accommodated, if needed. Verifying impacted organizations. Canceling a work request or requesting more information from requestor, when needed. Approving the work request for submission to IT. Denying a work request. Validating and approving the business priority and justification. Making the final determination of approving or denying a work request when the additional approvers have not reached a consensus.
BSP Coordinator
2.22.1.3.5 (02-05-2024) BSP Coordinator An individual BSP office coordinator is assigned to work requests created by their respective BOD/FODs once the request has been approved by the requesting organization. Their role, as it relates to the UWR process, is to review the work request for completeness and assess the justification to determine whether to submit the request for ERB approval if the Requested Implementation Date (RID) falls within the ERB Filing Season Review period. The requestor will be required to enter additional information to adequately justify why the request should be considered during the ERB Filing Season period. Work requests submitted with a RID outside of this range will not be reviewed by the ERB and will go directly to IT. The BSP coordinator may approve a work request for submission to the ERB and IT, defer the request until a later date, deny the request or send the request back to the requestor for more information.
ERB Coordinator
2.22.1.3.6 (02-05-2024) ERB Coordinator A member of the Executive Review Board (ERB) Team who reviews and evaluates work requests tagged for ERB approval (which has been approved by the BSP office) and schedules the request for formal ERB reviews. The ERB coordinator is responsible for ensuring the request is ready for review, scheduling the review, and conducting the review with the ERB. The ERB determines whether to approve the request for submission to IT, defer the request, deny the request or send the request back to the requestor for more information. If the request is being submitted during the ERB review cycle, the following additional information is required and will be the primary factors in obtaining ERB approval: The reason the UWR is late and the reason for the change, if applicable. A description of the impact if the UWR is not completed as requested. The requestor will state the impact (in terms of cost, opportunity lost, customer service, continuous improvement, etc.) if the request is not approved as requested. The requestor can provide additional justification to support and strengthen the case for submitting the request and seeking approval for the requested implementation date during the ERB review period. Any documentation that acknowledges that pre-coordination with IT was completed. If a request is submitted and approved by the requesting organization during the ERB Review cycle and the Requested Implementation Date also falls within the ERB review time period, the requestor is required to seek pre-coordination approval from the supplier prior to submitting the request. The executive review board coordinator will not allow a WR to go forward without proof of pre-coordination. The requestor will then provide one (or more) IT contacts.
IT Support Organizations (Coordinators and Suppliers)
2.22.1.3.7 (10-01-2010) IT Support Organizations (Coordinators and Suppliers) Any IT Associate Chief Information Officer (ACIO) organization or resources supporting the UWR process and management of work requests via PPM-WRMS is a IT Support organization. The IT Support organizations have these responsibilities: Reviewing and processing approved work requests from the requesting organization. Providing the ICA Details and decision on a work request in the designated time frame. Overseeing the processing of the request that impacts IT. Contacting and coordinating with the requesting organization to complete the ICA and render a decision regarding the acceptance of the work outlined. Establishing and maintaining internal policies and procedures for the review, approval and clearance of work request documents in accordance with this IRM.
Business Planning and Risk Management
2.22.1.3.8 (12-27-2019) Business Planning and Risk Management The BPRM organization is the process owner of the Unified Work Request process. BPRM supports the IRS IT through demand and risk management, managing Enterprise Intake and leveraging the Integrated Release Plan and other repeatable processes to support risk-based decisions. This group shares demand and risk factor data and processes across IT, and specifically integrates demand processes and data with Enterprise Services. The primary BPRM staff that supports the Unified Work Request process is the Enterprise Intake (EI) Branch. EI is comprised of the following offices: Business Planning and Analysis (BPA) Technical Support Office (TSO) Work Request Support Office (WRSO)
Enterprise Intake (EI) Branch
2.22.1.3.8.1 (02-05-2024) Enterprise Intake (EI) Branch The Enterprise Intake Branch serves as the single point of entry for IT demand. The EI Branch manages the Enterprise Intake (EI) process and encompasses two key IT demand types: The Unified Work Request, which is the focus of this IRM, and Investment Proposals, which may include Development/Modernization/Enhancement (DME), Treasury Executive Office for Asset Forfeiture (TEOAF) process led by Criminal Investigation (CI), and IRS IT Modernization Business Plan (Mod Plan), are submitted under the Portfolio Investment Process (PIP). EI provides the information needed to help make informed investment select, reselect, and system retirement decisions that align with the IRS strategic direction. EI has merged the management of the UWR process, TEOAF, and DME process. Their goal is to provide a single point of entry to receive and analyze work requests and investment proposals to formulate recommendations for optimizing the IT portfolio. EI will provide information to governing bodies to help make informed investment select, reselect, and system retirement decisions that align with the IRS strategic direction. The EI process was developed in collaboration with BOD/FOD and IT stakeholders and provides the following benefits: Single Intake Process Ensures strategic alignment for DME investment proposals, as well as enhancement work requests. Maintains consistency and transparency in managing business needs. Business Needs Repository Provides one system to house all business needs/investment proposals submitted to IT (PPM-WRMS). Reduces the need for data calls throughout the year and recycling of past submissions. Identifies enterprise trends in business needs and critical gaps in IT capabilities. Enterprise Intake Group Engages IRS organizations to submit IT demand requests to enable continuous review of business needs. Fosters early engagement between business, enterprise architecture and other IT stakeholders to evaluate IT demand and determine alignment to the envisioned IRS Strategic Theme/Themes, as well as determine demand feasibility given available resources and budget. Delivers timely and thorough analysis to support informed IT investment decisions.
Business Planning and Analysis (BPA)
2.22.1.3.8.1.1 (02-05-2024) Business Planning and Analysis (BPA) Business Planning and Analysis (BPA) partners with IRS executives and external stakeholders to enable selection, planning and management of an IT investment portfolio that aligns with IRS strategic priorities and demonstrates business value. All funding requests must be submitted as a proposal through the Project and Portfolio Management (PPM) System, specifically via the Work Request Management System (PPM-WRMS). PPM-WRMS entry begins the submission process for investment proposals that seek funding for new or enhanced IT functionality to IRS systems, or to purchase commodities including such items as software licenses, telecom equipment and service, hardware and contractor installation services. All DME funding requests must have executive sponsor approval and meet the following criteria: Include clearly-defined proposed high-level capabilities Include a clear explanation of the risks to the IRS if the project is not funded Identify any impacts to financial systems Clearly identify a one-year usable segment of functionality Document alignment with the following: Repeatable Groupings, IRS Strategic Goals and IT Strategic Goals (IT ONLY) In addition to the above criteria, proposals will be reviewed for alignment with the EA Target Architecture. All DME proposals must meet current submission criteria and guidance. The executive sponsor has a vested interest in the proposal, provides clear direction, and has confirmed proposal alignment to the broader organizational vision. The executive sponsor should indicate their approval in either a memo or email, which should be an attachment to the proposal. Click HERE to access the Business Planning and Analysis (BPA) SharePoint site, which includes helpful process information. DME proposals should be submitted for demand that meets at least one of the criteria below: All new DME requests are considered for Above Core funding, after Core operations have been addressed. Above Core demand equates to new projects or Changes/modifications to existing systems to improve capability or performance, and to implement business process improvements. This category also includes new or enhanced IT functionality to IRS systems, or purchase of commodities such as software licenses, telecom equipment and service, and hardware and contractor installation services. In addition to Strategic Goal and Target EA alignment, priority considerations will be given only to those proposals that align to one of the following categories: Filing Season Critical Legislative Mandate Must Do For additional guidance regarding the BPA Office and the Proposal Process, please access the PIP Proposal Guidance Library.
Technical Support Office (TSO)
2.22.1.3.8.1.2 (12-27-2019) Technical Support Office (TSO) Resolving issues and incidents reported via the break/fix ticket process. This includes supporting issues at the individual work request and workflow level, reporting issues, configuration issues, etc. Coordinating, developing and maintaining Enterprise Service Desk level 2 support processes including: probe and response, assignment groups detail and ticket management. Providing subject matter expertise for the UWR process and PPM-WRMS workflow configurations. Developing, coordinating, maintaining and distributing the UWR process and supporting procedures. Making changes to a work request based on the user reported issues via coordination efforts or incident/problem tickets. Leveraging PPM-WRMS reporting for oversight of the end-to-end process of work requests. Providing administration support for PPM-WRMS module and process oversight including: PPM-WRMS Compliance reporting support and execution for viewing, enterprise reporting and resolving issues identified. PPM-WRMS administration responsibilities (user administration, license management, configurations, etc.). PPM-WRMS requirements collection, management and evaluation, configuration development and maintenance, configuration data management, and module application support including maintenance and coordination with Enterprise Operations support staff for vendor releases and changes. Ownership and management of the PPM-WRMS CCB and Configuration Management. Providing trend analysis and metric reporting for work request processing. Providing oversight tracking and reporting on the work request process to organizational stakeholders and IRS senior and executive management. Monitoring the IT level end-to-end process, from submission to closure of a work request. Developing and publishing PPM-WRMS training and communication products.
Work Request Support Office (WRSO)
2.22.1.3.8.1.3 (02-05-2024) Work Request Support Office (WRSO) Serves as members of the work request primary coordinator group queue. Members of this coordination group receive notification of every new work request submitted and assigns them to a specific primary coordinator for processing. Serves as the assigned primary coordinator, based on WRSO assignment chart, for a work request. Provides subject matter expertise for the UWR process and PPM-WRMS workflow configurations. Depending on process step, in coordination with the requestor, can make changes/edits to a work request. Serves as a liaison between the requestor and IT supplier organizations for issues related to the UWR process and repository. Develops, coordinates, maintains and distributes the UWR process and supporting procedures. Monitors the IT level end-to-end process, from submission to closure of a work request. Reviews the magnitude and scope of the Agile Enterprise Request forms and ensures required documentation is attached to determine if the form is ready for routing to the enterprise intake group subject matter expert (EIG SME) for review for analysis, impact assessment, and registration of Agile demand. Receives notifications when an AEI request form has been received. Self-assigns the Agile demand form based upon the WRSO Assignment Chart. The request should be assigned within 3 business days. Analyzes AEI Request entries against the attached documentation, determines whether the form is complete and requests clarification from requestor via e-mail or returning the form, if necessary.
Primary Coordinator (IT)
2.22.1.3.8.1.3.1 (02-05-2024) Primary Coordinator (IT) The primary coordinators reside within the Work Request Support Office (WRSO) and will be the primary contact for the work request while facilitating the UWR process between the requestors and ACIO coordinators. The primary coordinator responsibilities include: Returning incomplete or inaccurate work requests submitted by a requesting organization and requesting more information as needed. Reviewing submitted work requests to determine routing to the impacted ACIO organizations based on established guidelines. Creating and assigning ICA Summary Requests to each impacted IT ACIO organization for review and analysis. Reviewing and consolidating IT ACIO ICA requests for final disposition of the requestor submitted work request. Coordinating with the ACIO coordinators to provide a singular IT response to the work request. Facilitating and/or escalating, within current policy, any work request decision if the ACIOs impacted are not in agreement for final disposition and response. Analyzing AEI Request forms against required documentation, determining whether it is complete, and requesting clarification from the requestor, if necessary. Forwarding AEI Request forms to the EIG SMEs for further review and ultimate registration of AEI Demand.
Supplier Organization (IT - ACIO)
2.22.1.3.9 (02-05-2024) Supplier Organization (IT - ACIO) A supplier organization is an IT organization that provides information technology products and services to another organization. Their responsibilities include: Providing initial requirements review and impact assessment for pre-coordination. Reviewing requests to determine whether the supplier organization may be impacted by the request. Estimating costs and staff resources for each work request where the potential for impact has been determined. Reviewing, analyzing and coordinating high-level requirements/business needs, designs, processes, business rule sets, or business rules with the requestor, and responding appropriately. Delivering IT products and services that satisfy work request requirements if resources (i.e., staff, budget, infrastructure, etc.) are available or providing justification for denying a request. Designating organizational level ACIO coordinators, division/domain coordinators and supplier resources to receive, control, evaluate and respond to work requests for their products and services. Establishing and maintaining internal policies for the review and clearance of work requests in accordance with this IRM. Considering available resources, workload, strategic plans, and budget to determine the implementation date on approved requests. Providing justification to the requesting organization when a work request is denied and recording any expended costs within the work request. Preparing a response or determining a new response due date within 90 calendar days for Enhancement and Legislative WRs and 90 calendar days for O&M and Rust WRs of the requesting organization's approval of the work request.
ACIO Coordinator (IT)
2.22.1.3.10 (02-05-2024) ACIO Coordinator (IT) The IT supplier ACIO coordinator is the central supplier organization's point of contact for the UWR process and is the requestor approver's counterpart. Their responsibilities include: Tracking and controlling work requests and related ICA Summary Requests within the supplier organization. Managing the ACIO coordinator queue. They will be required to assign by name all newly received ICA Summary Requests to an ACIO coordinator for processing (Note: at least one ACIO dispatcher is required to have access to the queue). Updating PPM-WRMS with any changes to assigned work requests. Reviewing the work request's related reports/information and advising the supplier organization management accordingly. Reviewing ICA Summary Request responses for completeness. Acting as a liaison between the primary coordinator contact and requestor contact(s) and organization resources (ACIO approvers, division coordinators). Updating, reviewing and approving ICA request responses to ensure a consolidated ACIO response is submitted. Tracking work requests to ensure timely disposition, updates/responses and delivery of products and services, if approved. Reviewing all work requests and ICA Summaries to determine the appropriate resources needed to complete the ICA Details Request. Assessing initial ICA Summary Requests and responding with Not Impacted by the request, as appropriate. Creating ICA Details work requests for the ACIO division level queues. Providing approval and completing a consolidated response (dates, cost, etc.) on the ACIO ICA Summary Request(s). Monitoring requests in progress within the ACIO according to established internal ACIO and IT-wide policies and procedures (late responses, no activity, escalation, etc.). Coordinating across the IT ACIO divisions on integrated services and engaging requestors and/or request approvers, as needed during the process. Generating reports and maintaining oversight of the process within their ACIO organization.
ACIO Approver (IT)
2.22.1.3.11 (10-01-2010) ACIO Approver (IT) The IT ACIO supplier approver will have: The authority to approve a work request response for their organization. The approving official will have the authority to allocate and commit resources in their organization. The approval represents the commitment by IT to deliver products and/or services reflected on the work request by the scheduled implementation date. The authority to decide first if the work requests can be fulfilled, then ensuring accuracy of estimates for their organization. Estimates are calculated within the ICA Details Requests and summarized for the ACIO in the ICA Summary Request and validated and/or approved. For ACIO organizations, without a separate division approver, the ACIO approver may assume the role of the division/domain approver. The ability to facilitate and/or escalate within current policy any work request decision if the ACIOs impacted are not in agreement for final disposition and response.
Supplier Division/Domain Coordinator (IT)
2.22.1.3.12 (02-05-2024) Supplier Division/Domain Coordinator (IT) The IT supplier division/domain coordinator is the central supplier organization's point of contact for the UWR process and is the requestor counterpart. The IT ACIO supplier division/domain coordinator responsibilities include: Assigning a supplier resource(s) within the division/domain to complete the ICA Details Request. Managing the ACIO supplier division (domain) coordinator queue. They will be required to assign by name all newly received ICA Details Requests to an ACIO division/domain coordinator for processing (Note: at least one ACIO supplier division/domain coordinator or dispatcher is required to have access to the queue). Reviewing work requests related reports/information and advising the requesting organization's management accordingly. Reviewing and approving ICA Details Request responses for completeness. Acting as a liaison between the ACIO coordinator contact and supplier resource personnel. Updating, reviewing and approving ICA Details Request responses to ensure a consolidated ACIO division (domain) response is submitted. Identifying the appropriate division approver(s). Tracking requests assigned to the division or domain to ensure timely updates/responses and ensuring timely disposition and delivery of products and services. Monitoring requests in progress within the ACIO supplier division/domain according to established internal procedures.
Supplier Division/Domain Approver (IT)
2.22.1.3.13 (10-01-2010) Supplier Division/Domain Approver (IT) The division approver will be responsible for approving the estimates from their division on the ICA Detail Request. Estimates are rolled up to the ACIO coordinator in the ICA Summary Request which is approved by the ACIO approver. For ACIO organizations without a separate division coordinator, the ACIO approver may assume this role.
Supplier Resource (IT)
2.22.1.3.14 (02-05-2024) Supplier Resource (IT) The IT supplier resource(s) responsibilities will include: Compiling and entering estimated cost and effort information in consideration of the attached high-level requirements/business needs, designs, processes, business rule sets, or business rules in the ICA Details Request for the supplier division and ACIO level approval. Coordinating with ACIO, division coordinators and requestor as needed to resolve issues or gather information. Monitoring ICA Details Requests and providing timely responses in accordance with policies and procedures. Tracking and updating PPM-WRMS with any changes to assigned work requests. Completing an approved or denied ICA Details Request with actual resources expended.
PPM-WRMS Reporting
2.22.1.3.15 (02-05-2024) PPM-WRMS Reporting Users can generate a variety of reports using PPM-WRMS. Reports are generated and distributed to management on a regular basis to inform stakeholders on the status of individual work requests and the overall performance of the UWR process tool. Work requests can be printed from PPM-WRMS by the end user, as well as dashboards and search results. PPM-WRMS will contain standard real-time dashboards containing information to be used to manage work requests for the following roles: All PPM-WRMS users Requestors BSP coordinators ERB coordinators Primary coordinators ACIO Coordinators Division/domain coordinators Supplier resources Executives Compliance and Reporting Dashboards Each PPM-WRMS user has the capability to create different information views using the product dashboard views comprised of standard portlets, or graphical overviews, of information. Please see the WRMS Dashboards, Reporting and Frequently Used Searches documentation that can be located on the BPRM WRMS website. Additional specific searches can be saved at the user level to configure and provide the transparency to work request information as needed. Enterprise Reporting – Enterprise level reports have been defined and created. Details will be included in the WRMS Dashboards, Reporting, and Frequently Used Searches supplement to the WRMS User Guide.
Work Request Submission (Registering IT Demand)
2.22.1.4 (02-05-2024) Work Request Submission (Registering IT Demand) In conjunction with the requesting organization's internal business processes and procedures, the work request originator, request approver, and other designated personnel will need to complete the activities listed below before creating a work request in order to facilitate the process. Note: To submit a work request, the requestor ensures that the work request is submitted timely and pre-coordinated as needed for complete high-level requirements/business needs, designs, processes, business rule sets, or business rules submission with the requesting organization approval in alignment with the requesting organization's process. Major steps in the submission process include: Identification and documentation of business requirements priority (see the Requirements Engineering Program Office for requirements guidance), business justification and determining the work request type. Preparation and submission of the work request. Pre-coordination of the work request with potentially impacted parties, including other requestors and/or suppliers for additional data and requirements specifications. Pre-coordination of the work request with the primary coordinator in WRSO for assistance, if the requestor is unsure which supplier ACIO area may be impacted. Approval of the work request by the designated request approver within the submitting organization prior to submission to IT. Approval of the work request by the BSP/ERB coordinators, if the work request was submitted with a RID that falls within the annually established ERB submission guidance. Work requests submitted with a RID outside of this range will not be reviewed by the ERB and will go directly to IT.
Work Request IT Review and Decision (Evaluation)
2.22.1.5 (02-05-2024) Work Request IT Review and Decision (Evaluation) After the work request is approved by the requestor's approving official, IT will review, coordinate, analyze, cost, and prepare a formal response within 90 days for Enhancement and Legislative WRs and 90 days for O&M and Rust WRs of the approval or coordinate with the requestor for an extension. Based on the product, services and/or requirements submitted, the request is reviewed for impact by IT supplier organizations. Several steps are taken during the review of the work request to determine if the requirements are sufficient to provide an impact cost analysis for resources such as budget and staff availability within the 90 days for Enhancement and Legislative WRs and 90 days for O&M and Rust WRs. The request can be: Returned for more information, Approved for delivery/implementation, Adjusted to update the time frame for delivery, Determined as having no impact, or Denied The major steps in the review process are: Reviewing the initial submitted request for completeness, Identifying the impacted IT supplier organizations based on the high-level requirements/business needs, designs, processes, business rule sets, or business rules, Distributing and completing the impact cost analysis for impacted IT organizations, Coordinating a consolidated IT response to the requestor (approved, denied, etc.), and Completing the impact cost analysis information for the actual cost upon implementation and/or delivery of an approved work request. If a request is denied, the impacted organizations will capture any expenditures that were realized in the analysis process, so that they will also be recorded. This is the start of the Work Request Management System (WRMS) Process Overview. Box 1 Level 1 Work Request Required. Box 2 WR created, reviewed and approved. Box 3 BSP/ERB Approval Process. Box 4 Level 2 IT Primary Coordination. Box 5 Impact Cost Analysis (ICA) Summary. Box 6 ICA Summary. Box 7 ICA Summary. Box 8 ICA Summary. Box 9. Box 10 Level 3 ACIO Dispatcher/Coordinators. Box 11 ICA Details. Box 12 ICA Details. Box 13 ICA Details. Box 14 Level 4 Division Dispatchers & Coordinators/Resources. Box 15 Division Coordinators assigns to Resource, who enters cost & scheduling info. Then Division and ACIO Approvers approve. Box 16 Level 5 Final Disposition. Box 17 BPRM consolidates ACIO ICA Summaries and Approve or Denies. Box 18 Resources enter actual staff days & costs. Box 19 Work Completed. Please click here for the text description of the image.
Work Request Types
2.22.1.5.1 (02-05-2024) Work Request Types The work request types are: Enhancement - Improvement work which enhances the current production environment (CPE). May be subjected to applicable investment management criteria processes, this enhancement should either: Improve an essential operational system; Create a new capability to support the IRS Business Mission; Improve processes and/or efficiency of CPE to meet needs of future SLA; Support Senior Executive Mandates and mandates by other agencies including but not limited to Treasury (including Chief Counsel and TIGTA and GAO). (ex. supporting a specific modernization system or project, moving an application developed outside of IT for integration into the infrastructure, converting an existing database (i.e. MS Access) to an EA compliant product or platform, and new work to enhance an existing project/system; or Create requests for IT products and services beyond the scope of sustaining operations, operations & maintenance (O&M), rust replacement or break/fix (IRS Service Central tickets) as enhancement or improvement work. This includes, but is not limited to: Changes to current production environment (CPE) applications; Development of new internally developed applications; New hardware beyond the scope of rust replacement; Hardware upgrades beyond the scope of sustaining operations; New commercial off-the-shelf (COTS) software products; or Upgrades for COTS products beyond normal operations and maintenance. When the requestor selects Enhancements as the WR type, the primary coordinator: Reviews the request for proper categorization and completeness; Works with the requestor to close any gaps; and Coordinates with the primary coordinator/BPA for additional review for additional review as part of the Administrative Review process. Legislative - Request to register demand for disposition for IT products and/or services to support an enacted legislative action. Sustaining Infrastructure (Rust) - Demand request for IT products and/or services to replace existing outdated assets as determined by IT policy to meet SLAs. Sustaining Infrastructure Operations & Maintenance (O&M) - Demand request for IT products and/or services to maintain current operating levels (O&M). (Includes those previously classified as an MWR request).
PPM-WRMS Functional Work Request Flow
2.22.1.6 (12-27-2019) PPM-WRMS Functional Work Request Flow PPM-WRMS is the authoritative, centralized repository for work requests. PPM-WRMS can be accessed through PPM-WRMS Database or the WRMS Home Page. PPM-WRMS maintains, distributes, and tracks work requests and associated documentation, attachments and responses. The PPM-WRMS is also a management and reporting tool. The flow of work request processing within PPM-WRMS can best be characterized in terms of the three key components produced: The Work Request (WR) – Created and approved within the requesting organization, it includes specifics on the work being requested, including any relevant attachments. The Impact Cost Analysis Summary (ICA Summary) – Summarizes the estimated cost, resources and impacts for a given ACIO relative to the work request. Once the work request is completed, it also summarizes the actual cost and resources figures for the ACIO. There may be one or more ICA Summaries per work request, depending on the number of ACIOs impacted. The ICA Details – Contains the detailed cost, resource and impact estimates from each specific supplier within a given ACIO. Once the work is completed, the ICA Detail is populated with actual costs and resources expended, and these numbers roll up to the ICA Summary. There may be one or many ICA Details for each ICA Summary. Coordination roles and functions exist between each of the above: To identify, for a given work request, the potentially impacted ACIOs and notify them of the need to complete ICA Summaries. To identify, within each ACIO, potentially impacted domains/divisions so that they can solicit ICA Details from them. To assign, within the individual ACIO domains/divisions, specific individuals to complete the ICA Details. Estimates and approvals flow back up through this chain as do actual cost and resource figures, once the work has been completed. PPM-WRMS facilitates this workflow and overall work request management. Requests for additional information and other workflow variations are also supported, along with tracking dashboards, notifications of required actions, notifications to remind users that an action is required, and reporting and navigating work requests. The following sub-sections describe this workflow and the associated functions in more detail, with an emphasis on the core policies and procedures associated with the work request process.
Work Request Submission
2.22.1.6.1 (02-05-2024) Work Request Submission The requestor submits a work request that was approved by their organization for submission to IT. Any request still in the draft stage may be withdrawn or deleted by the requestor.
Pre-Coordination Process
2.22.1.6.2 (02-05-2024) Pre-Coordination Process When the requestor submits the Unified Work Request (UWR), it goes to pre-coordination to engage with IT suppliers to ensure that the UWR is ready for formal submission. Once the pre-coordination is complete, the requestor updates the pre-coordination table in the UWR. The request is then reviewed by the primary coordinator to determine if it can proceed to the requesting organization for approval.
BSP Coordination
2.22.1.6.3 (02-05-2024) BSP Coordination Once approved by the requesting organization and before submission to IT, the request is reviewed by the BSP office to determine if the WR is complete and to assess the justification to determine whether to submit the request for ERB approval if the RID falls within the ERB filing season period. The BSP coordinator may approve a work request for submission to the ERB and IT, defer the request until a later date, deny the request or send the request back to the requestor for more information.
ERB Coordination
2.22.1.6.4 (02-05-2024) ERB Coordination When the BSP approves the request for ERB review, a member of the ERB team will ensure that the request is ready for review, determine whether to approve the request for submission to IT, defer the request, deny the request or send the request back to the requestor for more information. The following information will be required to obtain the ERB approval. A justification explaining the reason for the change and the late submission date, if applicable. A description of the impact in terms of cost, opportunity lost, customer services, continuous improvement, etc. Any documentation that acknowledges that pre-coordination with IT was completed. The requestor will be required to provide one (or more) IT contacts, if there was pre-coordination.
Work Request Primary Coordination
2.22.1.6.5 (02-05-2024) Work Request Primary Coordination Once the WR is approved by the requesting organization and has completed, if required, the BSP/ERB process, the system assigns the work request to the primary coordinator queue for assignment: The primary coordinator will review the request including the responses to the work request determination questions, to ensure it is complete and to assess the impacted ACIO organizations. In the event the impacted ACIO organizations cannot be determined, a request will be sent to all ACIO coordination groups for analysis. The assigned primary coordinator will create and assign an ICA Summary request for each potentially impacted ACIO coordinator queue group. If appropriate the primary coordinator can: Request more information via PPM-WRMS from the requestor, or Deny the request with the appropriate justification. Once all ICA Summary Requests are completed, the primary coordinator will review and consolidate all the responses for final disposition of the initial (parent) work request, recording the response and, if approved, the scheduled implementation date. An evaluation and analysis are required by all impacted IT suppliers before a commitment is made to provide the requested IT products and services. If the ACIO organizations responses are not in agreement, the primary coordinator will first try to resolve it with the ACIO coordinators, then elevate as needed to senior and/or executive management. Please see BPRM UWR SOP #004 - Resolving Conflicting ICA Summaries for additional guidance.
Enterprise Intake (EI) Process
2.22.1.6.6 (02-05-2024) Enterprise Intake (EI) Process The EI process allows IRS organizations to register IT demand as represented by the Work Request (WR), , Mod Plan, Treasury Executive Office for Asset Forfeiture (TEOAF), and DME Investments Proposals and Agile Enterprise Intake form for IT products and services. The EI process provides transparency for all stakeholders and facilitates a standardized submission and response, while supporting the coordination between requesting organizations and suppliers in all process and phases. While DME, TEOAF and Mod Plan proposals are part of the EI process, they are processed separately from work requests by BPA, as mentioned earlier in IRM Section 2.22.1.3.8.1 Enterprise Intake (EI) Branch. For further guidance on Investment Proposal processing within EI, please refer to Proposal Requestor training. Please reference the Enterprise Intake Process for a more detailed description of the Enterprise Intake process.
Agile Enterprise Intake (AEI) Process
2.22.1.6.6.1 (02-05-2024) Agile Enterprise Intake (AEI) Process The Agile Enterprise Intake (AEI) Process allows IRS organizations using the Agile Development Methodology to capture and implement IT products and services via high-level capabilities. The AEI process supports programs/projects that are using the agile development methodology to register their IT products and services demand through the Unified Work Request (UWR) process, when using the Micro Focus Project and Portfolio Management (PPM) tool . The process supports projects using the agile development methodology by integrating existing processes and data with the least possible project burden and disruption of iterative value delivery. The AEI Process is a component of the Enterprise Intake (EI) Process for capturing IT demand. The AEI process allows IRS organizations to register and track agile IT demand for products and services. The AEI process allows IT organizations, as part of an Integrated Project Team (IPT), to become engaged early in the project planning phase to ensure collaboration, socialization, agreement and approval of the high-level project scope of work. The agile development methodology is an incremental process characterized by small, frequent releases developed in close collaboration with the customer. Agile projects start with a conceptual vision of the solution and simply proceed through a series of sprints (set time frames for completing work) that include elaboration, development, test, and deployment. The AEI process provides enterprise transparency for agile demand (e.g., executive dashboard, metrics, reports) to improve integration of high-level information available for decision makers and governance bodies to help make informed IRS strategic direction decisions. The AEI process provides a streamlined UWR process to support agile IT demand. PPM-WRMS includes a new WR type for capturing agile IT demand, known as the Agile Enterprise Intake (AEI) Form. The Agile Enterprise Intake (AEI) Form must clearly identify the following: High Level Work Statement Cost, Very Rough Order of Magnitude (VROM) Resources Needed Estimated Planned Product Review (PPR) Estimated Integrated Readiness Review Requestors must attach supporting agile project validation documentation Information from lean business case (LBC) as part of the product prioritization process may be used to complete the Agile Enterprise Intake Form. Information from the Agile Central Vision Scope and Architecture (VSA) and or Project Charter may be used to complete the Agile Enterprise Intake request. The IRS customer organization submits the Agile Enterprise Intake Form into PPM-WRMS. The WRSO primary coordinator receives an e-mail notification alerting them that the AEI Requests has been received. The primary coordinator self-assigns the Agile Enterprise Intake Form , reviews the magnitude and scope of the submitted form, ensures required documentation is attached, and determines if the form is ready to be routed to the enterprise intake group subject matter expert (EIG SME) review for analysis, impact assessment, and registration of Agile demand. The primary coordinator forwards the Agile Enterprise Intake Form to EIG SMEs for further review and ultimate registration of AEI demand. EIG SMEs provides impact and resource availability and presents any findings at the EIG meeting. AEI demand is registered. For additional guidance about the Agile Enterprise Intake process please access the WRMS website.
Work Request ACIO Coordination
2.22.1.6.7 (02-05-2024) Work Request ACIO Coordination Once an ICA Summary is created and assigned to the ACIO organization by the primary coordinator, the ICA Summary Request is systemically assigned to the specific ACIO coordinator queue for assignment. The ACIO dispatchers with privileges to the ACIO coordinator ICA Summary queue will be notified and required to assign the request by name to an ACIO coordinator. The ACIO coordinator will review the parent work request including the responses to the work request determination questions for analysis of impact to their organization. The assigned ACIO coordinator will create an ICA Details Request for each potentially impacted ACIO division/domain - additional details can be found in the WRMS User Guide. If appropriate, the ACIO coordinator can: Deny the request with the appropriate justification Or respond as no impact Once all ICA Details Requests are completed, the ACIO coordinator will review, consolidate and approve the responses and estimates for final disposition for the ACIO organization. This includes recording a summarized response and, if approved, the scheduled implementation date. In the event the ICA Details responses are not in agreement, the ACIO coordinator will use an internal process to secure a consolidated decision regarding the ACIO commitment to delivering the product or service.
Work Request ACIO Division/Domain Coordination
2.22.1.6.8 (02-05-2024) Work Request ACIO Division/Domain Coordination Once an ICA Details Request is created by the ACIO coordinator, the ICA Details Request is systemically assigned to the specific division/domain coordinator queue for assignment: All organizations will have division/domain level coordinators. The division/domain coordinators with privileges to the division/domain coordinator work request queue will be notified and required to name assign the ICA Details Request to a division/domain coordinator. The division/domain coordinator will review the parent work request including the responses to the work request determination questions for analysis and the summary request to determine the impact to their organization. The assigned division/domain coordinator will assign by name the ICA Details Request to an individual supplier resource(s). If appropriate, the division/domain coordinator can: Request more information via PPM-WRMS to the requestor, Request an extension to the response due date, or Respond as no impact. In the event the ICA Details responses are not in agreement, the division/domain coordinator(s) will work with the ACIO coordinator and follow the internal process to secure a consolidated decision.
Work Request IT Supplier Resource Analysis
2.22.1.6.9 (02-05-2024) Work Request IT Supplier Resource Analysis Upon assignment of an ICA Details Request, the supplier resource will review the request and all associated requests and documentation, to provide estimates for costs and resources. The supplier resource will record all detail information for costs and staff estimates in consideration of the high-level requirements/business needs, designs, processes, business rule sets, or business rules as detailed in the estimates table of the ICA Details Request. If appropriate the supplier resource can: Return the ICA Details Request to the division coordinator for more information, re-assignment or to request an extension to the response due date, Contact the requestor informally by phone or e-mail outside of PPM-WRMS, or Recommend Denial in the comments field for the division approver to review and concur. The supplier resource will be required to update the ICA Details Request once the designated IT product/service is implemented. The actual costs, implementation date and resource expenditures need to be entered and the work request completed. The supplier resource will be required to update the ICA Details Request with actual costs and hours that are expended for requests that are denied.
Work Request Notifications
2.22.1.7 (10-01-2010) Work Request Notifications The WRMS User Guide will outline the details for notifications. Notification will be sent for: status changes to all impacted users and roles during the processing of the work requests, and for certain conditions, for example: reminders for action.
Work Request Statuses
2.22.1.8 (12-27-2019) Work Request Statuses The following section contains a list of the status codes displayed on the request types as they are processed end-to-end. The tables below may be changed as workflow steps are updated. It is important to note that there are status dependencies between the parent work request and the supporting child ICA Requests (i.e. work request to the ICA Summary Request, ICA Summary Request to the ICA Details Request.) Some status changes on the parent work request will be driven by the processing of the child request.
Work Request- Parent Request (e.g., Legislative, Operations and Maintenance (O&M), RUST replacement, Enhancement)
2.22.1.8.1 (02-05-2024) Work Request- Parent Request (e.g., Legislative, Operations and Maintenance (O&M), RUST replacement, Enhancement) The following table depicts status code values that occur during the work request lifecycle. Step Status Description Pending Pre-Coordination Supplier Meetings A work request is awaiting the Requestor to schedule a pre-coordination meeting with impacted IT suppliers and complete the pre-coordination table. Pending Pre-Coordination Outcome Confirmation A work request is awaiting the primary coordinator to review and confirm the pre-coordination meeting outcome. Pending Work Request Review Users in the Additional Reviewer(s) field have an opportunity to review the request for a number days, as specified by the requestor. Once each additional reviewer(s) has reviewed the request or the days for review have expired the request is returned to the requestor allowing them to review feedback provided by the additional reviewer(s). Pending Requestor Confirmation The requestors can update the work request and forward it for approval. Pending Requesting Organization Approval A work request is awaiting approval by the requesting organization. Pending Additional Approval A work request is awaiting approval by additional approvers within the requesting organization. The requestor can use this step to withdraw the request. Pending More Information Returned to requestor for more information. Pending BSP Approval BSP Approval Sub-Workflow. Pending BSP Coordinator Assignment A work request is ready to be assigned to a BSP coordinator team member. Pending BSP Coordinator Review Review of a work request in progress by BSP coordinator. The BSP coordinator assigned to the work request will either: approve, defer, deny, or return the request for more Information. Deferred by BSP Deferral of a work request in progress by BSP coordinator. The BSP coordinator must enter notes and a deferral review date, if the request is deferred. SYS - BSP Denied A system generated step: The BSP coordinator must enter notes and a denied reason, if the request is denied. SYS - BSP Need More Information A system generated step. The requesting organization approver must re-approve the request when the request is returned for more information. SYS - BSP Approved A system generated step: BSP approved requests will be routed to the ERB review process. Pending ERB Approval ERB approval sub-workflow. ERB Coordinator Assignment A work request is ready to be assigned to an ERB coordinator team member. Pending ERB Coordinator Review A work request is being reviewed and scheduled for an ERB review by the ERB coordinator. Pending ERB Review A review by the executive review board has been scheduled. The ERB coordinator assigned to the work request will update the work request based on the ERB decision to: approve, defer, deny, or return the request for more information. Deferred by ERB Deferral of a work request in progress by the ERB coordinator. The ERB coordinator must enter notes and a deferral review date if the request is deferred. SYS - ERB Need More Information The ERB coordinator must enter notes and select a reason for more information when sending the request back to the BSP coordinator review step when more information from the requestor is required. SYS - ERB Denied The ERB coordinator must enter notes and a denied reason, if the request is denied. SYS - ERB Approved The ERB approved requests are routed to IT for submission. Pending Primary Coordinator Assignment A work request has been approved and is in the queue awaiting assignment to a primary coordinator team member (IT). Pending Primary Coordinator Review A review of a work request is in progress by the primary coordinator. Create ICA Summary-1 An execution step where the ICA Request is created and populated with like data. Pending Requestor Review The primary coordinator denies the work request. Awaiting the requestor reviews to accept the decision or to escalate. Pending Work Request Escalation The requestor has escalated the work request when it is denied by the primary coordinator and the requestor does not agree with decision. Awaiting requestor action. Pending Impact Cost Analysis Awaiting the collection of all costs, staffing and impact analysis by suppliers. Create ICA Summary-2 An execution step where the ICA request is created and populated with like data. Pending Final Disposition of Work Request All information has been collected from suppliers. Awaiting the primary coordinator's determination/negotiation of the final disposition before approved/denied is selected. Pending Requestor Review of Denial Awaiting the requestor's review of denied work request and response that the requestor either agrees or chooses to escalate. Pending Work Request Escalation of Denial The requestor has escalated the denial of the work request. Work Effort in Progress The work request has been approved and work is underway. Pending Final Review of Denial Awaiting the completion of final review of the denial. Work Request Completed The requestor agrees that the work was delivered and the request is closed. Work Request Denied The final determination for denied work requests. All escalations have been exhausted. Withdrawn The final status for withdrawn work requests. Cancelled The final status for cancelled work requests. Cancelled-Partial Implementation Used whenever AD determines that a WR is impacted by tax reform. For non-tax reform WRs that are in "Work Effort in Progress" status and the ICAS/ICAD is in "Work Effort Scheduled" status, PPM/WRMS will systemically notify all impacted supplier resources, ACIO/division/domain coordinators and ACIO/division approver(s). SYS-Requestor Review Used to drive status changes.
ICA Summary Request (Opened for Each Impacted ACIO)
2.22.1.8.2 (02-05-2024) ICA Summary Request (Opened for Each Impacted ACIO) The following table depicts status values for the ICA Summary requests. Step Status Description Pending Supplier ACIO Coordinator Assignment The supplier ACIO dispatcher, where the workgroup for each ACIO can access the request and assign it to the appropriate supplier ACIO coordinator. Auto-populates Submission Date and Submission Fiscal Year after the ICA Summary request is submitted to the ACIO. Pending Supplier ACIO Coordinator Review The supplier coordinator receives the ICA Summary Request, reviews request, determines if the supplier organization is impacted, and assigns the supplier division coordinator and (if known) the supplier resource(s) who will perform the impact cost analysis. Create ICA Details-1 The step where the ICA Details are created from the ICA Summary workflow. Pending Impact and Cost Analysis The Impact Cost and Analysis Summary (ICAS) is awaiting collection of all costs, staffing and impact analysis from suppliers. It verifies at least one of the ICA Details has been created. If there is not at least one child, the ICAS will return to the supplier ACIO coordinator. Create ICA Details-2 The step where the ICA Details are created from the ICA Summary workflow. Pending Supplier ACIO Coordination After the ICA Details estimates have been completed the ICA Summary automatically moves to this step for the supplier ACIO coordinator to do final coordination before sending the request for approval. Pending Change Control Board (CCB) Review The step where the request is sent while it is awaiting CCB. This CCB Review is an internal process that may differ within each organization. Pending Supplier ACIO Approval The supplier ACIO approval of the ICA Summary. Approved The request will remain here until it has been approved and all the ICAs are moved to Work Effort Scheduled. Once approved the system rolls up the estimated cost and effort to the WR and, if it is the final ICA Summary, then it moves the WR to final disposition. Work Effort Scheduled No Action: WR has been approved and work effort is scheduled. The next action will take place on the ICA Details after the work has been implemented. The supplier resources will input the actual cost and effort and this request will be automatically updated. Work Effort Complete The work has been completed. The system rolls up the actual cost and effort to the WR. Denied The ICA Summary is denied by the supplier ACIO approver. The system rolls up the estimated cost and effort to the WR and, if it is the final ICA Summary, then it moves the WR to final disposition. Not Impacted The supplier is not impacted by work request. The supplier ACIO coordinator checks to see if ICA Details exist. If one exists then the ICA Summary cannot be set as not impacted. Cancelled The work request was cancelled; therefore, the ICA Summary is cancelled.
ICA Details Request (Assigned to Supplier Resource)
2.22.1.8.3 (02-05-2024) ICA Details Request (Assigned to Supplier Resource) The following table depicts status values for the ICA Detail requests. Step Status Description Pending Supplier Division Coordinator Assignment The supplier division queue, where the workgroup for each division can access the ICA Details Request and assign it to the supplier division coordinator. Pending Supplier Division Coordinator Review The supplier division coordinator receives the request, reviews request, determines if the division is impacted, and assigns the supplier resource(s) who will perform the impact cost analysis. Pending Impact Cost Analysis The assigned supplier resource(s) inputs costs and staffing hours and conducts impact analysis on the ICA Details. Pending Supplier Division Coordination The ICA Details coordination effort managed by the supplier division coordinator. It may include requesting an extension, requesting additional information or reassigning the request to another supplier resource. Pending More Information The ICA Details is returned to the requestor for more information. Pending Primary Coordinator Review of Extension The primary coordinator review and approve or deny the request for extension of response due date. Pending Supplier Division Approval The supplier division's approval of the ICA Details. Pending Additional Approval ICA Details approval by additional supplier division approvers within the division. Approved No action. The request will remain here until the WR has been approved and all the ICAs are moved to Work Effort Scheduled. The system rolls up the estimated cost and effort to the ICA Summary and, if it is the final ICA Details Request, then it moves the ICA Summary to final disposition. Work Effort Scheduled Work in progress: Once the work effort is complete the supplier resources will update the Actual Cost and Effort Details table component and click complete. Work Effort Complete The work has been completed. The ICAD rolls up the actual hours and costs to ICA Summary. Not Impacted The supplier is not impacted by work request. Check to see if this request is the final ICA Details Request. If it is the final ICA Details Request and the Not Impacted button is clicked, then the system moves the ICA Summary to final disposition. Denied The ICA Details Request is denied by supplier division approver. The system rolls up the actual cost and effort to the ICA Summary and, if it is the final ICA Details Request then the system moves the ICA Summary, to final disposition. Denied Pending Actuals The ICA Details was denied and supplier resources need to update the Actual Cost and Effort Details table component and click actuals entered. Denied Pending Actuals The WR or ICA Summary was Denied and supplier resources need to update the Actual Cost and Effort Details table component and click actuals entered. Cancelled Pending Actuals The WR was cancelled and supplier resources need to update the Actual Cost and Effort Details table component and click actuals entered. Cancelled The WR was cancelled. The system rolls up the actual cost and effort to the ICA Summary. SYS–Set Scheduled Implementation Date Consolidates all the Estimated Implementation Dates in the Estimated Cost and Effort Details table component and takes the greatest date and auto-populates the scheduled implementation date on the ICA. Assigned Used to force status dependencies. This will enable the request to continue through the workflow. Complete Consolidates all the Estimated Implementation Dates in the Estimated Cost and Effort Details table component and takes the greatest date and auto-populates the Scheduled Implementation Date on the ICA.
Agile Request Form Statuses
2.22.1.9 (02-05-2024) Agile Request Form Statuses The following table depicts status values for the Agile Request Form. Step Status Description Pending EI Analyst Assignment The status that an AEI form displays when it first comes into the IT (BPRMs') queue. Pending Internal S&P Review The status consisting of a detailed review of the AEI form by WRSO IA. The determination of routing the form to EIG IT SMEs for further review or returning form to the requestor for or additional information is made at this point. Pending Release to IT SME This status displays after a detailed review of the AEI form by WRSO IA, just before the form is routed to the IT SMEs in batch format. Pending IT SME Review The status that displays during the period that the IT SMEs are reviewing the AEI form. Ready for EIG The status that displays once the AEI form has returned from IT SME Review. Pending Enterprise Intake Group Review The status that displays during the EIG meeting, where a determination is made whether to cancel or approve/register the Agile Demand Request. Need More Information This status is displayed when the AEI form is returned to the requestor for additional information. Agile Demand Registered The status that is displayed once an AEI form is officially registered in PPM-WRMS.
Work Request Standards
2.22.1.10 (02-23-2024) Work Request Standards A work request is mandatory to record business demand for IT products/services with the exception of IT break/fix tickets and IRS Service Central requests. A work request must include a requested implementation date. All work requests submitted during the ERB filing season review period will be routed through the Business System Planning (BSP) and ERB approval processes prior to submission to IT. IT must provide a final decision on the work request (approve/deny) and scheduled implementation date within 90 days of the submission of the work request. IT may request an extension of this response due date. Any such request must be accompanied by a justification for the delay. If IT is unable to provide a final decision during the prescribed time frame then the requestor can escalate the work request. For guidance on escalating a WR, see WRMS User Guide - Unified Work Request WRMS Guidance and Procedure Handbook - BPRM UWR SOP #001 - Escalation of Work Request or UWR Process Issue Additional information regarding the escalation process can also be located below in IRM 2.22.1.11 Escalating a Denied Work Request A work request will contain a single requested implementation date and set of requirements. If requirements are to be satisfied in several staged releases, each with its own requested implementation date, a separate work request is required for each release. If IT determines that scheduling fulfillment of a given set of high-level requirements/business needs, designs, processes, business rule sets, or business rules can only be met in a series of implementation/delivery dates these additional dates can be included in the notes with a single scheduled implementation date representing the final completion of the work request. Any requests for services or products meeting the criteria in the WRMS Submission Deadline Memorandums must follow the procedures outlined there. The WRMS Submission Deadline Memos can be located in the WRMS Library. All late submissions will require documentation and justification as outlined in the memorandums. This documentation will include, but is not limited to, an explanation of the business impact if the requested service is not delivered in the proposed time frame. Sign off by the organizational head-of-office must also be included. If Sensitive But Unclassified (SBU) information is required to be submitted with a work request, that information must be attached using standard IRS encryption and access to it coordinated by the requestor. All work requests will require a business priority as follows: Low – Requests that have been submitted but are lower in priority for fulfillment, Normal – Request submitted timely for consideration in the designated time frames, High - The requesting organization is requiring implementation in less than 90 days for Rust and Enhancement WRs and 90 days for O&M and Rust WRs or the work request is determined to be a late submission as outlined in the annual submission guideline memo, or Critical – The requesting organization has identified the request as a critical business need and can demonstrate in the justification the value and impact if the request is not satisfied (e.g. Legislatively mandated requests with a directed implementation date). High and critical requests will require additional justification with a business impact and value summary. In addition, a setting of high or critical is required when a work request is submitted late, as outlined in the annual submission deadline memorandum. The UWR process is complete when the impacted IT supplier organization(s) delivers the final product or service, including providing the actual cost and resource expenditures. The IT resource supplier must record the work request actual costs and resources within 30 days of implementation and/or delivery. When the IT supplier denies a WR, they will provide a reason for denial. IRM Section 2.22.1.10, Escalating a Denied Work Request - provides a standard process for escalating work request issues. Examples of potential reasons for escalation include: Work request denial, A scheduled implementation date that is unacceptable to the requestor, or A post implementation issue recorded by the requestor. If a WR has completed the denial process and is closed, it cannot be reopened. If escalation results in a resolution or agreement on terms of the work request, the requesting organization must open a new work request and reference the denied request. As a work request is processed, all high-level requirements/business needs, designs, processes, business rule sets, or business rules, supporting documentation, and appropriate customer communications (e-mail, contact memoranda, or meeting minutes), are to be recorded or attached/linked to the work request. Throughout the processing of a work request additional information may be requested. The individual making the request will be required to submit a narrative and select one of the following reasons to justify their request for additional information: Insufficient Requirements, Missing Late Submission Approval, Missing Mandatory Documents, Clarification Required, or Other.
Escalating a Denied Work Request
2.22.1.11 (02-05-2024) Escalating a Denied Work Request Resolution of a denied WR is accomplished by negotiation between the requestor organization and the supplier organization. This negotiation will be elevated to the appropriate executive level needed for an agreement. If the requestors and suppliers can resolve the escalation without using the formal process, they should do so and notify the work request primary coordinator of the agreed upon decision. The key to successfully managing the denied escalation process is communication; early, often, and open communication between the requestor and the Supplier with the assistance of the primary coordinator, if needed. Successful negotiations between the requestor and Supplier organizations can result in the following, depending on ACIO specific constraints: A change to the Scheduled Implementation Date (SID) to accommodate delivery of the WR; A modification to the scope of the WR to facilitate delivery of services; A trade-off of scheduled work in order to accommodate delivery of the request, etc; or Work performed with no changes to the WR. Requestors are notified of the denial through various communications: Systemic notifications that a denial is pending, issued via PPM-WRMS (Applies when entire WR is denied), E-mail notifications from the BPRM primary coordinator based on the results of Impact and Cost Analysis Summaries - Impact and Cost Analysis Summary (ICAS), or E-mail notifications from the IT suppliers reporting that they cannot do the work.
Initiating the Escalation
2.22.1.11.1 (02-05-2024) Initiating the Escalation A denial escalation is initiated by the requestor selecting to escalate a work request that has been returned as denied. The requestor must also: Complete an assessment of the business impact and provide a clear statement of the burden if the work request is not approved. This business impact assessment must be included with any escalation of a denied work request. The statement of business impact should be included in the work request notes (preferred) or attached to the work request in PPM-WRMS. Gain concurrence on the escalation from the organization's business system planning (BSP) representative/designee or corresponding IT executive/designee. Include a statement of this concurrence in the work request notes. Initiate the escalation in PPM-WRMS (See the WRMS Guidance and Procedures Handbook, SOP 002 for details).
Procedure for Denying and Escalating a Denied Work Request Overview
2.22.1.11.2 (02-05-2024) Procedure for Denying and Escalating a Denied Work Request Overview Impacted suppliers determine a WR cannot be delivered and respond documenting the reason/justification for denial. The BPRM primary coordinator validates the legitimacy of the denial from the IT supplier, notifies the requestor via e-mail and formally executes the denial systemically thru PPM-WRMS. The requestor determines whether to accept the denial or whether to escalate the WR that has been denied. The requestor has 14 days from the date of denial to either complete the escalation process or agree with the denial. The WR will be closed if not acted upon by the requestor within the 14 days. If the requestor accepts the denial, no further action is required by the requestor. If the requestor does not accept the denial, the requestor can escalate the WR. The requesting organization is responsible for elevating the issue of the denial up through management to the executive level. The requesting executive will negotiate with the executive representative of each domain/division that has denied the WR. The requesting organization has 14 days from the day of denial to complete negotiations, achieve consensus regarding the denied WR and notify the primary coordinator. If concurrence among all impacted executives cannot be reached, then negotiations can be continued at a higher level or the WR will be denied. If negotiations continue at a higher level, the requesting organization will notify the primary coordinator to allow additional time. Please see BPRM UWR SOP #002 - Escalating a Denied Work Request of the WRMS Guidance and Procedures Handbook for more detailed guidance. The WRMS Guidance and Procedures Handbook can be accessed from the WRMS website - User Guides.
Procedure Details
2.22.1.11.3 (02-05-2024) Procedure Details Supplier Denial of a Work Request: The supplier domain/division(s) has evaluated a WR and has concluded that the WR cannot be fulfilled. The supplier notes the reasons/justification for denial, and elects to deny a WR. BPRM Primary Coordinator Denies a Work Request: When a supplier denies a WR, the BPRM primary coordinator reviews the notes and reason for the denial, then follows-up, if needed, with the supplier organization to understand the reason why the work request cannot be fulfilled. The BPRM primary coordinator will notify the requestor of the denial and the reason for the denial via e-mail, prior to executing the denial escalation. These proactive steps may avoid the need to deny the WR. After reviewing the notes and reason for denial, and consulting with both the supplier and requestor organizations, the BPRM primary coordinator will deny the WR. The work request is then routed to the requestor for review. The requestor can either accept the denial or disagree with the denial. The requestor has 14 days from the date of denial to decide. If the WR is not acted upon within the 14 days, the request will be closed with the final status of "Denied". Requestor Initiates the Escalation/Executive Negotiation: A denial escalation is initiated by the requestor for a WR that has been returned or denied. (See the WRMS User's Guide for more details on WR Escalation.) When escalating, the requestor is responsible for elevating the denial information up to the appropriate executive level within their organization. The escalation of a denied WR form must be completed and provided to the appropriate supplier organization, and attached to the WR. Executive signatures are required on the form regardless of the decision to either uphold or overturn the denial. If it is resolved to do the work, the requestor organization must notify the primary coordinator who will then reissue new costing assignments to the impacted ACIO organizations.
Work Request Disposition
2.22.1.11.4 (02-05-2024) Work Request Disposition Once negotiations are complete, the requestor organization will notify the BPRM primary coordinator with the results as "escalation approved" and work will be done, "approved with modifications", or "denial confirmed", and will include documentation for all impacted executives (i.e., approval/concurrence). BPRM facilitates the coordination and summary of findings, and updates the information to the work request. If it is determined the WR will be denied, the BPRM primary coordinator will complete the denial action. If the executives agree to reconsider the WR then the BPRM primary coordinator will issue new costing assignments to impacted ACIO organizations.
Response Due Date (RDD) Extension
2.22.1.12 (02-05-2024) Response Due Date (RDD) Extension This section describes the enterprise-wide standard process for requesting and recording a disposition for extensions to the RDD on a work request. An RDD represents the commitment to approve or record the denial of the work request for IT services and/or products by the given date. It does not include delivery; only the decision as to whether IT can perform the requested work. The standard commitment to requestors is that IT will make a determination on any work request within 90 calendar days for Enhancement and Legislative and 90 calendar days for O&M and Rust WRs after submission. This procedure outlines the steps to be taken to amend the RDD when a decision cannot be attained. A supplier has the option to request an extension to the default 90 day RDD on Enhancement and Legislative WRs and 90 day RDD on O&M and Rust WRs. (*Note: The RDD refers to the date by which the work request must be dispositioned as approved, denied or cancelled. Simply requesting more information or otherwise interacting with the requestor does not change the RDD). The process for requesting extensions is controlled by WRSO and the procedure and rules in the WRMS Guidance and Procedures Handbook - Standard Operating Procedures (SOP), specifically BPRM UWR SOP #011 – Handling No Impact ICA Summary and ICA Details Requests. These documents can be located by selecting the User Guides tab on the BPRM WRMS website.
Procedure for Requesting RDD Extensions
2.22.1.12.1 (02-05-2024) Procedure for Requesting RDD Extensions The process originates with the supplier resource responsible for providing cost and time estimates for a particular ICA Detail associated with the work request. The supplier resource thoroughly documents the basis for the request and forwards it to the supplier division coordinator. After validating that all the required information has been provided, the supplier division coordinator forwards the request to the primary coordinator. The primary coordinator determines whether to: Return the request for a more complete justification, Approve the extension request immediately and notify the requestor, or Notify the requestor and facilitate a disposition between the supplier and requestor. Once the extension is approved, the primary coordinator updates the RDD and notifies the requestor that this has been done.
Requesting a Response Due Date Extension
2.22.1.12.2 (02-05-2024) Requesting a Response Due Date Extension A request for an RDD extension begins with the supplier resource-the individual identified on an associated ICA Detail request as being responsible for providing cost and resource estimates. The first step, before formally requesting an RDD extension, is for the supplier resource to contact the work request requestor, discuss the work thoroughly, and outline the need for the extension. This step will facilitate swift acceptance of the requested extension. Once the matter has been discussed between supplier and requestor, the supplier resource must, return the ICA Detail to the supplier division coordinator (the individual responsible for assigning the ICA Detail Request). The supplier resource must include the following in the ICA Detail Request notes: The reason(s) why the RDD extension is needed, The impact on the organization if it is not granted, The proposed RDD extension - number of calendar days beyond the current RDD, and. The rationale for the number of additional calendar days requested. See the WRMS User's Guide for details on how this is accomplished within PPM-WRMS. Rules: If the requested RDD extension is less than 45 calendar days the primary coordinator will ensure the proper procedure has been completed, contact the requestor, and make the change. This notification should be annotated in the work request notes. If the requested RDD extension exceeds 45 calendar days the notes must also include certification of approval by the supplier ACIO approver or their designee. If this is the second RDD extension request on this ICA Detail (i.e., a previous extension request was already accepted) then Notes must be attached with a new justification, including all points a-d noted above in paragraph (3). The notes must also include certification of approval by the supplier ACIO approver or their designee. If this is the third or more RDD extension request on this ICA Detail or the response date extension request exceeds 90 additional calendar days then: Notes must be attached with new justification, including all points a-d noted above. The notes must also include certification of approval by the supplier ACIO. e) Response Due Extensions that exceed the requested implementation date will need additional coordination with the requestor. If this is problematic for the requestor the issue will need to be elevated using the same method as escalating a denied request, and an impact statement from the requestor is needed.
Forwarding the Response Due Date Extension
2.22.1.12.3 (02-05-2024) Forwarding the Response Due Date Extension When the supplier resource returns the ICA Detail and escalation request to the supplier division coordinator, the supplier division coordinator: Verifies that all the necessary information has been provided as per IRM 2.22.1.11.2, Requesting a Response Due Date Extension and all the referenced rules have been met. If not, the ICA Detail is sent back to the supplier resource to provide this information (or the supplier division coordinator can choose to add the missing information directly). Selects extension required which formally logs the extension request and forwards the extension request to the work request primary coordinator.
Accepting the Response Due Date Extension
2.22.1.12.4 (02-05-2024) Accepting the Response Due Date Extension Upon receiving a request for an RDD extension the primary coordinator will: Verify that all the necessary information has been provided and rules have been met as described in IRM 2.22.1.11.2, Requesting a Response Due Date Extension. If not, the primary coordinator returns the extension request to the supplier division coordinator with the notes on what information is required or what rules need to be met. The primary coordinator also sends an e-mail to the supplier ACIO coordinator, notifying them that the request for extension has been returned to the supplier division coordinator. Once all necessary information has been provided and rules met, the primary coordinator proceeds as follows If the extension request is for 45 calendar days or less, the primary coordinator accepts the extension request and updates the RDD on the work request, and notifies the requestor that this has been done. (Note: The RDD must also be manually updated on all associated ICA Summary and Detail requests. See the WRMS User's Guide for details.) If the extension request is for more than 45 calendar days, then the primary coordinator sends a standard e-mail (sample below) to the requestor: "An extension to the RDD of greater than 45 calendar days has been requested by the supplier on your work request #________. The specifics can be found in Notes associated with ICA Detail request #_________. If you accept this RDD extension, please respond promptly to this e-mail. A rapid response will help expedite the supplier estimation process (the supplier may elect to suspend work on a response to your work request pending your acceptance of the extension request). If the requested extension to the RDD is unacceptable, please respond promptly to this e-mail with a complete explanation of the impact to your organization and the IRS if this RDD extension were to be accepted. If you do not respond within 14 calendar days, the RDD extension request will be accepted." If the requestor responds with an acceptance of the extension or if 14 calendar days have expired with no requestor response, the primary coordinator accepts the extension in PPM-WRMS and enters the updated RDD as described above. If the requestor responds stating that the requested response due date is unacceptable, the primary coordinator, after first ensuring that the included impact statement is clear and complete, applies guidelines described in WRMS Guidance and Procedures Handbook, specifically SOP #001– Escalation of Work Request or UWR Process Issues. This document can be found on the BPRM WRMS website. If it is determined that the escalation is not to be accepted, the primary coordinator documents the decision in the ICA Detail notes and returns it to the supplier division coordinator.
Exception - Specifying an Extended RDD on a Submitted Work Request
2.22.1.12.5 (02-05-2024) Exception - Specifying an Extended RDD on a Submitted Work Request Organizations may log advance demand for IT services in future years, well in advance of the expected delivery of service. When this is the case, the work request may be submitted to IT well before complete requirements are known and any IT response is expected. In these cases the default 90 day response period for Enhancement and Legislative WRs or 90 day response period for O&M and Rust WRs is certain to be exceeded. In this situation, or in any case where the requestor knows in advance that a supplier response later than 90 days for Enhancement and Legislative WRs or 90 days for O&M and Rust WRs is acceptable, the following procedure should be applied: The requestor includes a note in the Notes section of the work request stating: "This work request is being submitted well in advance of the anticipated service delivery date for the purposes of recording future demand. The requested RDD for this work request is "MM/DD/YYYY". In other words, the requestor should specify the acceptable RDD in advance, rather than requiring the supplier to go through the subsequent mechanics of formally requesting and justifying an RDD extension. The primary coordinator, upon receiving a work request with an extended RDD already specified by the requestor, updates the default RDD to the later date identified by the requestor. Please note that the supplier has the discretion when determining what is considered "complete requirements". The supplier organization may decide to return the WR if the requirements are not sufficiently detailed to allow them to properly evaluate the impact of the work. IT always has the option to return a WR when they have determined that the requirements are insufficient. It is strongly suggested that the requestor pre-coordinate with the primary coordinator and the supplier organization(s) before submitting a WR where the requirements do not allow them to properly evaluate the impact to their organization.
WRMS IRM - Figure 1 WRMS High Level Process Overview
Exhibit 2.22.1-1 WRMS IRM - Figure 1 WRMS High Level Process Overview This is the start of the Work Request Management System (WRMS) Process Overview. Box 1 Level 1 Work Request Required. Box 2 Work Request created, reviewed and approved. Box 3 BSP/ERB Approval Process. Box 4 Level 2 IT Primary Coordination. Box 5 Level 3 ACIO Coordination. Box 6 Impact Cost Analysis (ICA) Summary Box. Box 7 ICA Summary Box. Box 8 ICA Summary. Box 9 ICA Summary. Box 10 Level 4 Division Coordination. . Box 11 Request for ICA Details. Box 12 Request for ICA Details. Box 13 Request for ICA Details. Box 14 Request for ICA Details. Box 15 Level 5 Final Disposition. Box 16 Work Request updated with disposition - consolidated ACIO ICA Summary responses. Box 17 Level 6 Work Completed. Box 18 Work Request Actuals Updated. Box 19 Level 7 Customer Feedback (Post Implementation Review). Please click here for the text description of the image.
Terms and Acronyms
Exhibit 2.22.1-2 Terms and Acronyms Term Definition ACIO Coordinator The IT ACIO coordinator is the central supplier organization's point of contact for the UWR process and is the request approver's counterpart. The IT ACIO supplier coordinator's responsibilities include tracking and controlling work requests within the supplier organization. ACIO Supplier Approver The IT ACIO supplier approver has the authority to approve a work request response for their organization. The approving official will have the authority to allocate and commit resources in their organization. The approval represents the commitment by IT to deliver products and/or services reflected on the work request by the scheduled implementation date. AEI Agile Enterprise Intake AGILE A set of software development principles emphasizing ongoing collaboration between the customer and the self-organizing, cross-functional delivery teams. Agile promotes early and frequent value delivery, empowerment,, technical excellence, and process adaptability throughout the life-cycle of the project. There are a number of specific Agile methods and practices, such as Scrum, Extreme Programming, etc. BODS/FODS Business Operating Divisions/Functional Operating Divisions, also known as the requestors. BPRM Business Planning and Requirements BSP Business System Planning BPA Business Planning and Analysis Business Process What the enterprise must do to conduct its business successfully. A business process comprises actions taken to respond to particular events and produce particular results, and may cross multiple business functions or organizations. CCB Change Control Board CFO Chief Financial Officer Commercial Off-the-Shelf Software (COTS) Pre-packaged computer software for a particular purpose or application developed by a vendor for sale to numerous companies and organizations. Dashboard A dashboard is a defined set of specified portlets; a collection of various portlets with a common relationship. Development/Modernization/Enhancement (DME) DME and Treasury Executive Office for Asset Forfeiture (TEOAF) – Above core funding requests for new or enhanced IT functionality to IRS systems, or to purchase commodities (i.e., software, licenses, telecom, hardware, contractor installation services). Includes all new DME not considered as Key Legislative Programs such as the Taxpayer First Act (TFA) and the Bipartisan Budget Act 2015 (BBA).DME requests include TEOAF proposals, which are Treasury Forfeiture Fund (TFF) IT requests to support new DME and Operations & Maintenance (O&M) administered by Criminal Investigation (CI). Dispatchers Receive requests, identify and name assign individual coordinators. Drafts Drafts are saved; not-submitted requests. EIB Enterprise Intake Branch EIG Enterprise Intake Group - Reviews Agile requests and DME proposals. EIG SME Enterprise Intake Group Subject Matter Expert EPO Estimation Program Office ERB Engineering Review Board Executive Review Team (ERT) The ERT is co-led by the Strategy and Planning (S&P) ACIO and the Technical Advisor to the Deputy Commissioner, Services and Enforcement (S&E), and is comprised of members from FMS, BPA, and S&P. The ERT reviews the proposed DME portfolio and makes funding decisions to ensure that the funded DME portfolio aligns with the IRS strategic priorities and demonstrates business value. PPM Project and Portfolio Management Impact and Cost Analysis (ICA) Impact and Cost Analysis is the process in which a supplier evaluates the level of effort required to complete a work request. The analysis, recorded on summary and detail records, includes any contract, hardware, software, network costs and IRS staff hours. The request will also be reviewed to determine if the request can be delivered at the time requested, whether it is within the ACIO's submission window and if it is an approved and funded project. ICA Summary Summary of all costs, staffing and impact analysis by suppliers. ICA Details Collection of all costs, staffing and impact analysis completed by a single supplier resource; all ICA Details related to a work request are combined to produce the ICA Summary. Intake Coordinator (IC) (Formerly the WRC) conducts the admin review of the WR business needs. The WRSO acts as the IC. IRR Integrated Readiness Review IRS Strategic Goals The IRS enterprise strategic goals to which the proposal aligns. IT Strategic Goals IT Strategic Goals articulate the strategy for how IT will position itself to better serve its customers in an effective and sustainable manner, and promote a path to a healthier IT environment. Note: IT Strategic Goals are selected ONLY for proposals submitted by IT organizations. IT Contact The IT resource or resources that the requestor may have used in the past for similar requests. ITIL Information Technology Infrastructure Library IRS IT Modernization Business Plan (Mod Plan) A new proposal type for funding requests that fall under the IRS Modernization Plan; a six-year plan to modernize IRS business operations. The Mod Plan combines the future direction of information technology with the IRS business vision and strategy, as articulated in the IRS Strategic Plan. LBC Lean Business Case MVP Minimal Viable Product Notification PPM-WRMS will send an e-mail notification to a user set when a work request status is changed, an action is required or when a pre-defined time period has expired. O&M Operations and Maintenance Pre-Coordination The mandatory process to establish an integrated, cross-functional perspective of the Unified Work Request (UWR) throughout IT and to ensure that it is ready for formal submission to IT. The requesting organization meets with the IT suppliers to reach a determination on whether or not to proceed with formal submission of the WR in PPM-WRMS. Portlet A graphical overview of specific data sets that provide real time views of common data and filter specific information based on each user's needs. Portlets allow users to view the current status of a request at any point in time. PPM Project and Portfolio Management Primary Coordinator (PC) The primary coordinator resides within an IT operating division and will be a primary contact for the work request and facilitating the UWR process with the requestors and ACIO coordinators. The primary coordinator designated may be a work request coordinator in the Business Planning & Risk Management Division or a designated ACIO coordinator. PPR Product Planning Review PTS Project Tracking System Request Types PPM-WRMS request types (Legislative etc) Reviewer The requestor contact may designate (as needed) one or more additional impacted organizations and subject matter experts to ensure that all relevant requirements are identified prior to submission. The designated additional reviewers will be notified via e-mail to review the request before it is submitted. ROI Return on Investment Supplier Division/Domain Approver The division approver will be responsible for approving the estimates from their division. Estimates are rolled up to the ACIO coordinator in the ICA Summary Request. For ACIO organizations without a separate division coordinator, the ACIO approver will assume this role. Supplier Division/Domain Coordinator The IT supplier division/domain coordinator is the central supplier organization's point of contact for the UWR process and is the requestor counterpart. Supplier Division Resource The supplier division resource(s) responsibilities include completing an ICA and compiling the information for entry in the ICA detail request for supplier division and ACIO level approval. Supplier Organization Any IT organization that provides information technology products and services to another organization is a supplier organization. The IT ACIO supplier organization responsibilities include reviewing requests to determine whether the supplier organization may be impacted by the request and estimating costs and staff resources for each work request where the potential for impact has been determined. Target Enterprise Architecture (EA) The target EA details a five-year enterprise vision of IRS operations. TSO Technical Support Office VROM Very Rough Order of Magnitude Workflow A workflow consists of a logical series of steps that define a process from beginning to end. Workflow refers to the steps the request goes through within the tool in order to achieve completion. Workflow provides the utility to track and record the request process and information through out its life cycle. Work Request A documented formal request from any organization requiring IT services for changes to current or planned systems, corporate hardware or system testing, etc. Used for registering demand for IT products and services including hardware and software for an organizational level business need. NOTE: ICA Summary Requests or ICA Details Requests are children of the parent work request. Work Request Determination Questions A series of specific questions related to the type of work request. These questions are used to collect enough details to assist in the proper classification and routing of the work request. PPM-WRMS Project and Portfolio Management-Work Request Management System – based on Micro Focus PPM software, an ITIL-based product for managing demand requests for IT products and services. WRSO Work Request Support Office
Source: official text