2.22.1 Unified Work Request (UWR) Process 2.22.1.1 Program, Scope and Objectives 2.22.1.1.1 Purpose of the UWR IRM 2.22.1.1.2 Scope of the UWR IRM 2.22.1.1.3 Distribution of the UWR IRM 2.22.1.1.4 Audience 2.22.1.1.5 Responsibilities 2.22.1.1.6 Program Controls 2.22.1.1.7 Policy Owner 2.22.1.1.8 Program Owner 2.22.1.1.9 Primary Stakeholders 2.22.1.1.10 Progam Goals 2.22.1.2 Overview of the UWR Process 2.22.1.3 UWR Process Roles and Responsibilities 2.22.1.3.1 Requestor Organization (Business (BOD)or Functional Operating Divisions (FOD) including IT) 2.22.1.3.2 Requestor 2.22.1.3.3 Additional Requestor Reviewer(s) 2.22.1.3.4 Requestor Approver 2.22.1.3.5 BSP Coordinator 2.22.1.3.6 ERB Coordinator 2.22.1.3.7 IT Support Organizations (Coordinators and Suppliers) 2.22.1.3.8 Business Planning and Risk Management 2.22.1.3.8.1 Enterprise Intake (EI) Branch 2.22.1.3.8.1.1 Business Planning and Analysis (BPA) 2.22.1.3.8.1.2 Technical Support Office (TSO) 2.22.1.3.8.1.3 Work Request Support Office (WRSO) 2.22.1.3.8.1.3.1 Primary Coordinator (IT) 2.22.1.3.9 Supplier Organization (IT - ACIO) 2.22.1.3.10 ACIO Coordinator (IT) 2.22.1.3.11 ACIO Approver (IT) 2.22.1.3.12 Supplier Division/Domain Coordinator (IT) 2.22.1.3.13 Supplier Division/Domain Approver (IT) 2.22.1.3.14 Supplier Resource (IT) 2.22.1.3.15 PPM-WRMS Reporting 2.22.1.4 Work Request Submission (Registering IT Demand) 2.22.1.5 Work Request IT Review and Decision (Evaluation) 2.22.1.5.1 Work Request Types 2.22.1.6 PPM-WRMS Functional Work Request Flow 2.22.1.6.1 Work Request Submission 2.22.1.6.2 BSP Coordination 2.22.1.6.3 ERB Coordination 2.22.1.6.4 Work Request Primary Coordination 2.22.1.6.5 Enterprise Intake (EI) Process 2.22.1.6.5.1 Agile Enterprise Intake (AEI) Process 2.22.1.6.6 Work Request ACIO Coordination 2.22.1.6.7 Work Request ACIO Division/Domain Coordination 2.22.1.6.8 Work Request IT Supplier Resource Analysis 2.22.1.7 Work Request Notifications 2.22.1.8 Work Request Statuses 2.22.1.8.1 Work Request- Parent Request (e.g., Legislative, Operations and Maintenance (O&M), RUST replacement, Enhancement) 2.22.1.8.2 ICA Summary Request (opened for each impacted ACIO) 2.22.1.8.3 ICA Details Request (assigned to Supplier Resource) 2.22.1.9 Agile Request Form Statuses 2.22.1.10 Work Request Standards 2.22.1.11 Escalating a Denied Work Request 2.22.1.11.1 Initiating the Escalation 2.22.1.11.2 Procedure for denying and escalating a denied Work Request Overview 2.22.1.11.3 Procedure Details 2.22.1.11.4 Work Request Disposition 2.22.1.12 Response Due Date (RDD) Extension 2.22.1.12.1 Procedure for requesting RDD extensions 2.22.1.12.2 Requesting a Response Due Date Extension 2.22.1.12.3 Forwarding the Response Due Date Extension 2.22.1.12.4 Accepting the Response Due Date Extension 2.22.1.12.5 Exception - Specifying an Extended RDD on a submitted work request Exhibit 2.22.1-1 WRMS IRM - Figure 1 WRMS High Level Process Overview Exhibit 2.22.1-2 Acronyms & Terms 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 January 27, 2020 Purpose (1) This transmits revised IRM 2.22.1, Business Planning and Risk Management, Unified Work Request (UWR) Process. Material Changes (1) Interim Guidance IT-02-0719-0016, IRM 2.22.1.2 (4), Business Planning & Risk Management (BPRM), Unified Work Request (UWR) Process Overview of the UWR Process has been incorporated into this document. (2) IRM 2.22.1.2 - Overview of the UWR Process (4) was modified to provide additional guidance when submitting WR(s) that may have impact for IRS financial systems and related processes. (3) Modified IRM 2.22.1.2 - Overview of the UWR Process (5) - a link was added for Additional Guidance on Program Initiatives and Changes Affecting the IRS Financial Systems. (4) Modified IRM 2.22.1.2 - Overview of the UWR Process (5) - a link was added for Financial System Flagged Projects in WRMS SOP. (5) Added Sub-Section 2.22.1.6.5.1 - Agile Enterprise Intake Process - which incorporates the process that meet the needs of the Agile Development Methodology IT demand and services. (6) Added section 2.22.1.9 Agile Request Form Statuses (7) Section 2.22.1.11 Escalating a Denied Work Request has been revised. (8) Section 2.22.1.12 Response Due Date (RDD) Extension has been revised. (9) An Acronyms & Terms table has been updated. (10) Direct links to website references have been added. (11) The following editorial changes were also made throughout this document: Reviewed the IRM for editorial changes in accordance with the new Document 13275, IRS Style Guide. With the release of the IRS Style Guide, the grammar, punctuation and general writing rules in Document 12835, IRM Style Guide, are superseded. Reference to Doc. 12835 applies primarily to the IRM format and structure standards. Clarified the language throughout, and reviewed and updated all references and website addresses. Effect on Other Documents IRM 2.22.1, dated April 11, 2017, is superseded. Audience This IRM applies to all Internal Revenue Service (IRS), Treasury organizations and other official affiliates requesting or providing Information Technology (IT) products and services from IT. Effective Date (01-27-2020) Nancy A. Sieger, acting Chief Information Officer. 2.22.1.1 (01-27-2020) Program, Scope and Objectives 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 syste2020m 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 detailed 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 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 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 Introduction to PPM: Proposal and WRMS Modules ELMS class is mandatory for all new PPM-WRMS users. Additional PPM-WRMS training is available and highly recommended for all PPM users. A user's functional role in the process will determine the type of training needed. 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. Supplemental information related to the UWR process can be found on the BPRM WRMS website. 2.22.1.1.1 (10-01-2010) Purpose of the UWR IRM This IRM defines the UWR process and the policy for submitting and responding to work requests. 2.22.1.1.2 (10-01-2010) Scope of the UWR IRM The provisions of this IRM apply to the UWR process from the initial work request development through final disposition. This IRM addresses standards and policy for the preparation, submission, approval, coordination and control of work request documents and responses. 2.22.1.1.3 (12-27-2019) Distribution of the UWR IRM This IRM is available through the BPRM WRMS website and the IRS IRM website. 2.22.1.1.4 (12-27-2019) Audience This IRM applies to all Internal Revenue Service (IRS), Treasury organizations and other official affiliates requesting or providing Information Technology (IT) products and services from IT. 2.22.1.1.5 (12-27-2019) Responsibilities The Chief Information Officer ultimately is responsible for this IRM. 2.22.1.1.6 (12-27-2019) Program Controls This framework uses the IRS Internal Management Documents System to establish controls. This IRM section constitutes one of the controls. 2.22.1.1.7 (12-27-2019) Policy Owner The Chief Information Officer (CIO) is responsible for overseeing all aspects of our systems that operate the nation’s tax infrastructure. 2.22.1.1.8 (12-27-2019) Program Owner The BPRM Division of ACIO Strategy and Planning maintains the application, Project and Portfolio Management (PPM) which includes PPM-Work Request Management System (WRMS) (PPM-WRMS) module, and the 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 OS GetServices 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 OL5081 application 2.22.1.1.9 (12-27-2019) Primary Stakeholders All Internal Revenue Service (IRS), Treasury organizations and other official affiliates requesting or providing Information Technology (IT) products and services from IT. 2.22.1.1.10 (12-27-2019) Progam Goals The IRM provides the fundamental knowledge and procedural guidance for employees who submit or respond to request for any Information Technology (IT) product or services. By following the processes and procedures provided by this IRM, employees be able to better understand the completely understand the essentials of the UWR process. 2.22.1.2 (12-27-2019) 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. 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 GetIT requests for service Software/Infrastructure changes for IRS systems All work requests require a business priority with the exception of requests for demand from customers that follow the Agile Development Methodology. (Please see the IRM 2.22.1.6.5.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 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 request 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 PDFmemo 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 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's 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. 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. 2.22.1.3.1 (12-27-2019) 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. 2.22.1.3.2 (12-27-2019) 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. Pre-coordination is strongly encouraged because it is a critical activity in the work request submission process and can improve the quality of the requirements. Pre-coordination encourages early engagement of requestor, impacted organizations and IT suppliers potentially impacted by the work request. The requestor is responsible for: 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. Following internal work request policies and procedures established by the requestor organization in order to coordinate the work request for an organization. Using the work request Pre-Submission guide at the BPRM WRMS website. to prepare a work request. Collecting the information needed to prepare the work request. The requestor consults with other analysts or IT, as appropriate. 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. Using the PPM-WRMS to submit the work request. Submitting AEI Request forms into PPM-WRMS 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. 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 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. 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 him to review feedback, update the work request and forward it for approval. Designating approver(s) on each work request in compliance with requesting organization standards. 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. Identifying the IT points of contacts. Identifying impacted organizations. Serving as a point-of-contact or subject matter expert (SME) regarding an organization's business requirements. Identifying the business requirements, priority and justification (that is in alignment with your organizational priorities), for IT products and services. Gathering and documenting the business requirements, justification and needs. Determining a requested implementation/delivery date for product or service to be used by IT suppliers to assess during analysis. Ensuring information entered on the work request is complete and accurate. Serving as the requestor organization's primary representative in coordination with the IT Primary Coordinator and supplier contacts. Consolidating information and requirements to submit to the IT organization for evaluation. Obtaining late submission documentation and attach to work request, if required. Responding to supplier requests for additional information or requests for extensions relating to a work request. A standard process for extension request issues is located on the BPRM WRMS website. Please consult the UWR, WRMS Guidance and Procedures Handbook, BPRM UWR SOP #003 - Requesting & Entering a Disposition for a Response Due Date (RDD) Extension. Setting the priority of the work request in PPM-WRMS and provide documentation, as required. Responding to any requests for more information on the request throughout the process. Withdrawing or cancelling a request, if appropriate, as outlined in the WRMS User Guide. Escalating a denied request or any issue relating to the scheduled implementation date as proposed by the supplier. Submitting an incident ticket, as needed, to obtain PPM-WRMS or UWR process support from BPRM via phone call at 1-866-7HELP4U (1-866-743-5748) or TTY 1.866.HELP4U6 (1-866-435-7486) or via OS GetServices website or visit the BPRM WRMS website. 2.22.1.3.3 (12-27-2019) 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. 2.22.1.3.4 (12-27-2019) Requestor 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. Makes the final determination of approved or denied on a Work Request when the Additional Approvers have not reached a consensus. 2.22.1.3.5 (12-27-2019) 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 or not 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. 2.22.1.3.6 (12-27-2019) 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 filing season 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 Enterprise Intake analyst will not allow a WR to go forward without proof of pre-coordination. The Requestor will then provide one (or more) IT Contacts. 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 request via PPM-WRMS is a IT Support organization. The IT Support organizations have these responsibilities: Reviewing and processing approved work request 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 impact 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. 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 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) 2.22.1.3.8.1 (12-27-2019) 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 Proposals submitted under the Treasury Executive Office for Asset Forfeiture (TEOAF) process led by Criminal Investigation (CI) and Development/Modernization/Enhancement (DME) proposals 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 and TEOAF, and DME process. Their goal is to provide a single point of entry to receive and analyze work request 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. 2.22.1.3.8.1.1 (12-27-2019) 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 Themes and IT Vision Strategic Themes (IT ONLY) Include a Digital IRS Blueprint Include an IRS Technology Roadmap Include a Sequencing Plan 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 criterion 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 Future State and IRS IT Roadmap 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. 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: 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, requirements 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. 2.22.1.3.8.1.3 (12-27-2019) 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 name assigns them to a specific Primary Coordinator for processing. Serves as the assigned Primary Coordinator for a work request when required. Provides subject matter expertise for the UWR process and PPM-WRMS workflow configurations. Makes changes to a work request based on the user reported issues via coordination efforts or incident/problem tickets. 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 ensure 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 attached documentation and determines whether form is complete and requests clarification from Requestor via e-mail or return the form, if necessary. 2.22.1.3.8.1.3.1 (12-27-2019) Primary Coordinator (IT) The Primary Coordinator resides within an IT operating division and will be a primary contact for the work request while facilitating the UWR process between the requestors and ACIO coordinators. The Primary Coordinator designated may be a Enterprise Intake Coordinator (EIC) in the BPRM Division or a designated ACIO coordinator. The Primary Coordinator responsibilities include: Receiving new work requests and making assignments to an individual for IT primary coordination. Returning incomplete or inaccurate work request submitted by a requesting organization including 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. Analyzes AEI Request forms against required documentation and determines whether it is complete: and requests clarification from the requestor, if necessary. Forwards AEI Request forms to the EIG SMEs for further review and ultimate registration of AEI Demand. 2.22.1.3.9 (12-27-2019) Supplier Organization (IT - ACIO) Any IT organization that provides information technology products and services to another organization is a supplier organization. Their responsibilities include: Reviewing requests to determine whether 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 on work requests for their products and services. Establishing and maintaining internal policies for the review and clearance of work request 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 of the requesting organization’s approval of the work request. 2.22.1.3.10 (10-01-2010) 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 counterpart. Their responsibilities include: Tracking and controlling work requests and related ICA Summary Requests within the supplier organization. Serving as the assigned Primary Coordinator for work requests as required. ACIO coordinators or Dispatchers designated to manage the ACIO coordinator queue 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 work request 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 ensures 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. 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. 2.22.1.3.12 (10-01-2010) 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 request related reports/information and advising the Organization 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. 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. 2.22.1.3.14 (12-27-2019) 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 supplier division and ACIO level approval. Coordinating with ACIO and 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. 2.22.1.3.15 (12-27-2019) 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 Suppliers Resources Executives and 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 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. 2.22.1.4 (12-27-2019) 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 a number of activities 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, 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. 2.22.1.5 (12-27-2019) 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 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. The request can be: Returned for more information, Approved for delivery/implementation, Adjusted to update the time frame for delivery, or 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. 2.22.1.5.1 (12-27-2019) 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: 1) improve an essential operational system; 2) create new capability to support the IRS Business Mission; 3) improve processes and/or efficiency of CPE to meet needs of future SLA; 4) 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, New work to enhance an existing project/system, Supporting a senior mandate) 5) all requests for IT products and services beyond the scope of sustaining operations, operations & maintenance (O&M), rust replacement or break/fix (ITAMS 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 scope of rust replacement Hardware upgrades beyond scope of sustaining operations New commercial off-the-shelf (COTS) software products Upgrades for COTS products beyond normal operations and maintenance Any funding for new or enhanced IT functionality to IRS systems, or to purchase commodities (i.e., software licenses, telecom, hardware, contractor installation services) or requests for funding for two years out from current budget year for new or enhanced IT functionality that aligns to strategic priorities and can be a multi-year effort, and is technically complex in nature will require the submission of a DME Proposal Request. For additional Proposal Request guidance please contact the Business Planning & Analysis (BPA) SharePoint site. When the Requestor selects Enhancements as the WR type, the Intake Coordinator: Reviews the request for proper categorization and completeness. Works with the requestor to close any gaps, Coordinates with the Intake Analyst/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 (O&M) work request - Demand request for IT products and/or services to maintain current operating levels (O&M). (Includes those previously classified as an MWR request). 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 link 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 and notification to remind users that an action is required, and work request reporting and navigation. 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. 2.22.1.6.1 (10-01-2010) Work Request Submission The requestor submits a work request that was approved by their organization for submission to IT. Any request still in draft stage may be withdrawn or deleted by the requestor. 2.22.1.6.2 (12-27-2019) 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 or not 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. 2.22.1.6.3 (12-27-2019) 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 filing season pre-coordination with IT was completed. The Requestor will be required to provide one (or more) IT contacts, if there was pre-coordination. 2.22.1.6.4 (12-27-2019) Work Request Primary Coordination Once the WR was approved by the requesting organization and has completed the BSP/ERB process, the system assigns the work request to the Primary Coordinator queue for assignment: The Primary Coordinators will be notified and required to assign the request by name to a specific Primary Coordinator. 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 to 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 is required by all impacted IT suppliers before a commitment is made to provide the requested IT products and services. In the event 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. 2.22.1.6.5 (12-27-2019) Enterprise Intake (EI) Process The EI process allows the IRS organizations to register IT demand as represented by the Work Request (WR), New Ideas, 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 the New Ideas, TEOAF and DME proposals are part of the EI process, New Ideas and Investment Proposals are processed separately from work requests by BPA, as mentioned earlier in Section 2.2.1.3.8.1 of this IRM. 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 this process. 2.22.1.6.5.1 (12-27-2019) Agile Enterprise Intake (AEI) Process The Enterprise Intake Branch (EIB) has established a new Agile Enterprise Intake (AEI) Process to allow IRS organizations using the Agile Development Methodology to capture and implement IT products and services via high-level capabilities. This process was created in accordance with Enterprise Intake Branch’s (EIB) Process Improvement Initiative. The S&P Strategy team partnered with representatives from the BODs, FODs and Information Technology (IT) to develop the new Agile Enterprise Intake (AEI) process. The AEI process is needed to support 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 (formerly HP-PPM). The new streamlined 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 new 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 will allow 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. The IRS is adopting Agile to deliver value to the customer earlier and more often. 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. Agile offers a faster, more efficient alternative to the traditional waterfall life cycle development methodology. 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 new 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. All Agile Demand requests must have head of office or governance approval e.g. Strategic Development (SD) Executive Steering Committee (ESC) before being submitted to the Enterprise Intake Branch (EIB). The Agile Enterprise Demand request 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 Demand request. Information from the Agile Central Vision Scope and Architecture (VSA) and or Project Charter may be used to complete the Agile Enterprise Intake request. IRS customer organization submits Agile Enterprise Intake (AEI) Request form into PPM-WRMS 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 Demand form and expeditiously reviews the magnitude and scope of the submitted form as well as ensures required documentation is attached and determines if the form is ready to be routed for Enterprise Intake Group Subject Matter Expert (EIG SME) review for analysis, impact assessment, and registration of Agile demand. The Primary Coordinator forwards the AEI Request form to EIG SMEs for further review and ultimate registration of AEI Demand. EIG SMEs provide impact and resource availability and present any findings at the EIG meeting. AEI demand is Registered. For additional guidance about the Agile Enterprise Intake process please access the WRMS website. 2.22.1.6.6 (10-01-2010) 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. 2.22.1.6.7 (10-01-2010) 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, or 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 internal process to secure a consolidated decision. 2.22.1.6.8 (12-27-2019) 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, or 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. 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. 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 it is 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. 2.22.1.8.1 (12-27-2019) 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 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 him to review feedback provided by the Additional Reviewer(s) Pending Requestor Confirmation Requestors can update the work request and forward it for approval. Pending Requesting Organization Approval Work request is awaiting approval by the requesting organization. Pending Additional Approval 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 Work request is ready to be assigned to a BSP Coordinator team member. Pending BSP Coordinator Review Review of 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 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 System generated step: The BSP Coordinator must enter notes and a denied reason, if the request is Denied. SYS - BSP Need More Information System generated step. The Requesting Organization Approver must re-approve the request when the request is sent for more information. SYS - BSP Approved System generated step: BSP Approved requests will be routed to the ERB Review process. Pending ERB Approval ERB Approval Sub-Workflow ERB Coordinator Assignment Work request is ready to be assigned to a ERB Coordinator team member. Pending ERB Coordinator Review Work request is being reviewed and scheduled for an ERB review by the ERB Coordinator. Pending ERB Review 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 work request in progress by 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 is routed to IT for submission. Pending Primary Coordinator Assignment Work request has been approved and is in the queue awaiting assignment to a Primary Coordinator team member (IT). Pending Primary Coordinator Review Review of work request is in progress by Primary Coordinator. Create ICA Summary-1 Execution step where the ICA Request is created and populated with like data. Pending Requestor Review Primary Coordinator denies work request. Awaiting requestor reviews to accept decision or to escalate. Pending Work Request Escalation Requestor has escalated work request when it is denied by Primary Coordinator and the requestor does not agree with decision. Awaiting requestor action. Pending Impact Cost Analysis Awaiting collection of all costs, staffing and impact analysis by suppliers. Create ICA Summary-2 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 Primary Coordinator's determination/negotiation of the final disposition before Approved/Denied is selected. Pending Requestor Review of Denial Awaiting requestor review of denied work request and responses that requestor agrees or requestor chooses to escalate. Pending Work Request Escalation of Denial Requestor has escalated the denial of the work request. Work Effort in Progress Request has been approved and work is underway. Pending Final Review of Denial Awaiting completion of final review of denial. Work Request Completed Requestor agrees that work was delivered and request is closed. Work Request Denied Final determination for denied work request. All escalations have been exhausted. Withdrawn Final resting place for Withdrawn work request. Cancelled Final resting place for Cancelled work request. 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 will systemically notify all impacted Supplier Resources, ACIO/Division/Domain Coordinators and ACIO/Division Approver(s). SYS-Requestor Review Used to drive status changes 2.22.1.8.2 (12-27-2019) 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 Supplier ACIO dispatch, 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 Supplier coordinator receives 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) that will perform the impact cost analysis. Create ICA Details-1 Step where the ICA Details are created from the ICA Summary workflow. Pending Impact and Cost Analysis The Assigned Supplier resource(s) conducts Impact and Cost Analysis on the ICA Details. Verifies at least one ICA Summary has been created. If there is not at least one child it will return. Create ICA Details-2 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 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 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 actuals and this request will be automatically updated. Work Effort Complete Work has been completed. System rolls up the actual cost and effort to the WR. Denied ICA Summary is denied by Supplier ACIO Approver. 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 Supplier is not impacted by work request. Checks to see if ICA Details exist. If one exist then the ICA Summary cannot be set as Not Impacted. Cancelled Work request was cancelled; therefore the ICA Summary is Cancelled. 2.22.1.8.3 (12-27-2019) 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 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 Supplier Division Coordinator receives request, reviews request, determines if the division is impacted, and assigns the Supplier Resource(s) that will perform the impact cost analysis. Pending Impact Cost Analysis Assigned Supplier Resource(s) conducts impact cost analysis. Pending Supplier Division Coordination ICA Details coordination effort managed by the Supplier Division Coordinator. May include requesting an extension, requesting additional information or reassigning the request to another Supplier Resource. Pending More Information Returned to requestor for more information. Pending Primary Coordinator Review of Extension Primary Coordinator reviews and approves or denies request for extension of response due date. Pending Supplier Division Approval Supplier Division approval of the ICA Details. Pending Additional Approval ICA Details approval by additional approvers within 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. 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 Work has been completed. Rolls up the actual hours and costs to ICA Summary. Not Impacted Supplier is not impacted by work request. Check to see if this request is the final ICA Details Request then it moves the ICA Summary to Final Disposition. Denied ICA Details Request is denied by Supplier Division Approver. System rolls up the actual 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. 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 WR was Cancelled. 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. 2.22.1.9 (12-27-2019) 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 IT (BPRMs) queue. Pending Internal S&P Review Status consisting of detailed review of AEI form by WRSO IA. Determination of routing form to EIG IT SMEs for further review or returning form to Requestor for rework or additional information is made at this point. Pending Release to IT SME This status displays after detailed review of AEI form by WRSO IA, just before the form is routed to the IT SMEs in batch format. Pending IT SME Review Status that displays during the period that the IT SMEs are reviewing the AEI form. Ready for EIG Status that displays once the AEI form has returned from IT SME Review. Pending Enterprise Intake Group Review 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 Status that is displayed once an AEI form is officially registered in PPM-WRMS. 2.22.1.10 (12-27-2019) 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 GET-IT service requests. Submission of an approved work request represents the formal notification to IT that a product or service is needed. 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 in the prescribed time then the requestor can escalate the work request. For guidance on escalating a denied WR, see WRMS User Guide - Unified Work Request WRMS Guidance and Procedure Handbook - BPRM UWR SOP #002 - Escalating a Denied Work Request 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 notes, with single scheduled implementation date representing the final completion of the work request. Any requests for services or products meeting the criteria in the WRMS Policy Memorandum must follow the procedures outlined there. The WRMS Policy Memo can be located on the WRMS Library. All late submissions will require documentation and justification as outlined in that memorandum. 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, or Normal – Request submitted timely for consideration in the designated time frames, or High - Requesting organization is requiring implementation in less than 90 days or the work request is determined to be a late submission as outlined in the annual submission guideline memo, or 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 (e.g. Legislative 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 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 IT denies a WR they will provide a reason for denial. 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 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, or Missing Late Submission Approval, or Missing Mandatory Documents, or Clarification Required, or Other. 2.22.1.11 (12-27-2019) 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 Intake Analyst 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 Intake Analyst, 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; or modification to the scope of the WR to facilitate delivery of services; or 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), or E-mail notifications from BPRM Intake Analyst (IA) based on 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. 2.22.1.11.1 (12-27-2019) 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 User’s Guide for details). 2.22.1.11.2 (12-27-2019) 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 IA validates the legitimacy of the denial from the IT Supplier and notifies the Requestor via e-mail and formally executes the denial systemically thru PPM-WRMS. The Requestor determines whether to accept the denial or 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 and achieve consensus regarding the denied WR and notify the IA. 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 IA 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. 2.22.1.11.3 (12-27-2019) 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 Intake Analyst Denies a Work Request: When a Supplier denies a WR, the BPRM Intake Analyst will review the notes and reason for the denial. then follow-up, if needed, with the Supplier Organization to understand the reason why the work request cannot be fulfilled. The BPRM Intake Analyst 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 IA 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 the appropriate executive level within their organization. The Escalation of a Denied WR form (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 IA who will then reissue new costing assignments to the impacted ACIO organizations. 2.22.1.11.4 (12-27-2019) Work Request Disposition Once negotiations are complete, the Requestor Organization will notify the BPRM Intake Analyst with the results as either ”escalation approved” and work will be done, or “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 Intake Analyst will complete the denial action. If the executives agree to reconsider the WR then the BPRM Intake Analyst will issue new costing assignments to impacted ACIO organizations. 2.22.1.12 (12-27-2019) 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 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. (*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 #003 - Requesting & Entering a Disposition for a Response Due Date (RDD) Extension and 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. 2.22.1.12.1 (12-27-2019) 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. Based on guidelines described in WRMS Guidance and Procedures Handbook - SOP, specifically BPRM UWR SOP #003 - Requesting & Entering a Disposition for a Response Due Date (RDD) Extension, the primary coordinator determines whether to: Return the request for more complete justification, or 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. 2.22.1.12.2 (12-27-2019) Requesting a Response Due Date Extension A request for an RDD extension begins with the supplier resource, that 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 will obviously 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 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 his/her 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 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 his/her 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. Response Due Extensions that exceed the Requester Implementation Date will need additional coordination with the requestor. If this is problematic for the requestor the issue will need to be elevated in the same escalation as a denied request and an impact statement from the requestor is needed. 2.22.1.12.3 (12-27-2019) 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 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. 2.22.1.12.4 (12-27-2019) 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 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 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 – General Escalation of Work Request or UWR Process Issues. This document can be found on the BPRM WRMS website. If it is resolved 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. 2.22.1.12.5 (01-03-2012) Exception - Specifying an Extended RDD on a submitted work request Organizations may log advance demand for IT services in out 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 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 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 anticipated service delivery 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 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. 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. Exhibit 2.22.1-2 Acronyms & Terms Term Definition ACIO Coordinator The IT ACIO coordinator is the central supplier organization's point of contact for the UWR process and is the requestor approver counterpart. The IT ACIO supplier coordinator responsibilities include tracking and controlling work requests within the supplier organization. ACIO 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, frequent value delivery, 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 associated with and Private Debt Collection (PDC), the Bipartisan Budget Act of 2015 (BBA), Federal Investigative Standards (FIS), or Passport Tax Delinquency. DME requests include TEOAF proposals, which are Treasury Forfeiture Fund (TFF) IT requests to support new DME and Operations & Maintenance (O&M) administered by CI. Dispatchers Receive requests, identifies and name assigns 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 is charged to review the proposed DME portfolio and to make funding decisions to ensure that the funded DME portfolio aligns with IRS strategic priorities and demonstrates business value. HP PPM Hewlett Packard 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 as well as 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 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 Investment Review Team (IRT) The IRT meets annually to review DME proposals submitted by the due date specified in the investment guidance message issued for each investment cycle. IRS Strategic Themes The IRS enterprise goals or strategic themes to which the proposal aligns IT Vision Strategic Theme IT Vision Strategic Themes 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 Vision Strategic Themes 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 Roadmap The IRS Technology Roadmap is a set of interrelated views showing key elements of the IRS technology evolution. This pre-decisional document is intended to facilitate a dialogue among IRS business and IT leaders around the future direction, priorities, and how to align investments and resources to achieve a common vision. LBC Lean Business Case MVP Minimal Viable Product New Idea New Idea – Submitted to request review/evaluation services before submitting a formal proposal, to guide organizations to the best demand approach for their request. 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 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 contacts as 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 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. 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 within the tool the request goes through 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 work request type specific questions to collect enough details to assist in the proper classification and routing or the request and the impact cost analysis process 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 More Internal Revenue Manual