2.22.1 Unified Work Request (UWR) Process

Manual Transmittal

April 11, 2017

Purpose

(1) This transmits revised Internal Revenue Manual (IRM) 2.22.1, Business Planning & Risk Management (BPRM), Unified Work Request (UWR) Process, previously titled Requirements Management, Demand Management, UWR Process.

Material Changes

(1) Requirements and Demand Management (RADM) is now Business Planning & Risk Management (BPRM).

(2) Addition of the Enterprise Intake (EI) Office in BPRM

(3) Addition of the Business Planning and Analysis (BPA) section in EI

(4) Addition of the Enterprise Intake Process for processing Enhancement Work Requests (WR)

(5) WR Statuses have been updated.

(6) The graphic file has been revised.

(7) An Acronyms & Terms table has been added.

(8) Direct links to website references have been added.

Effect on Other Documents

IRM 2.22.1, dated September 11, 2012, 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

(04-11-2017)

S. Gina Garza
Chief Information Officer.

Introduction

  1. 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 process uses work requests to represent a contract between IT and our business and functional operating divisions (BODs/FODs). The UWR process focuses on collecting requests for IT products and services from IT into a single flexible system using a common set of processes and procedures. The Business Planning & Risk Management (BPRM) Division is responsible for the oversight of the IRS IT demand management program and the UWR process. The primary goal of the program is to register all demand for IT products and services, and provide transparency for data driven decision making for resource commitments. This includes collecting all related 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.

  2. Additionally, the BPRM Division maintains the software module, the Work Request Management System (WRMS), and 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 WRMS. All work requests will be processed using the established UWR process standards and WRMS module. All persons needing access to 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

  3. The 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.

  4. The HP-PPM's Proposal and WRMS Modules is mandatory for all new WRMS users. Additional WRMS training is available and highly recommended for all of the WRMS users. A user's functional role in the process will determine the type of training needed. The UWR process is supported by the 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.

  5. Supplemental information related to the UWR process can be found on the BPRM WRMS website.

Purpose of the UWR IRM

  1. This IRM defines the UWR process and the policy for submitting and responding to work requests.

Scope of the UWR IRM

  1. The provisions of this IRM apply to the UWR process from the initial work request development through final disposition.

  2. This IRM addresses standards and policy for the preparation, submission, approval, coordination and control of work request documents and responses.

Distribution of the UWR IRM

  1. This IRM is available through the BPRM WRMS website and the IRS IRM website.

Overview of the UWR Process

  1. The IRS BODs or FODs, also known as the requestor, determine a need for IT products or services and develops 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.

  2. 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

  3. All work requests require a business priority. 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 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).

  4. Work request resulting in new legislation and business initiatives that impact tax revenue receipts, refunds, frozen credits, or unpaid tax assessments may impact our financial systems. As a result, these changes must be coordinated with the Chief Financial Office (CFO) organization during the planning stages, prior to implementation. 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 CFO & Financial Systems Guidance for additional information.

  5. Work Requests 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.

  6. 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.

UWR Process Roles and Responsibilities

  1. The following describes the key roles and functional responsibilities in the UWR process supported by WRMS.

Requestor Organization (Business (BOD)or Functional Operating Divisions (FOD) including IT)

  1. Any BOD or FOD requesting IT support and resources, including IT itself, is a requestor organization. The requestor organization has the following responsibilities:

    • Identify specific business justification and requirements to register demand for IT resources.

    • Coordinate with the BSP staff to prioritize the business needs per its own organizational specific procedures, as appropriate. (This only applies to those organizations that have a BSP staff.)

    • Designate organizational level additional reviewers (if needed) and approvers for each assigned work request.

    • Document the IT contact, as appropriate, that may be a current or former supplier on a similar type of request for a specific product or service. Contact the Work Request Support Office (WRSO) Office in BPRM for assistance, if a contact cannot be identified.

    • Establish and maintain internal policies and procedures for the review and clearance of work request documents in accordance with this IRM.

    • Respond to work determination questions and information requested for work request type selected.

Requestor

  1. 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 WRMS to submit the work request.

    • 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 the 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 the 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.

Additional Requestor Reviewer(s)

  1. 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 email 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.

  2. 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.

Requestor Approver

  1. 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 ensures 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.

    • Validating and approving the business priority and justification.

BSP Coordinator

  1. 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.

ERB Coordinator

  1. A member of the Executive Review Board 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.

  2. 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.

IT Support Organizations (Coordinators and Suppliers)

  1. Any IT Associate Chief Information Officer (ACIO) organization or resources supporting the UWR process and management of work request via the 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.

Business Planning and Risk Management

  1. 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)

Enterprise Intake (EI) Branch
  1. 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)
      Budget Cycle (Pre-Select) proposals submitted under the Planning, Programming and Audit Coordination (PPAC) process
      Development/Modernization/Enhancement (DME) proposals submitted under the Portfolio Investment Process (PIP)

  2. 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, DME and Budget Cycle (Pre-Select) 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:

    1. Single Intake Process

      • Ensures strategic alignment for DME and Budget Cycle (Pre-Select) investment proposals, as well as Enhancement Work Requests.

      • Maintains consistency and transparency in managing business needs.

    2. Business Needs Repository

      • Provides one system to house all business needs/Investment Proposals submitted to IT (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.

    3. 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 Future State, as well as determine demand feasibility given available resources and budget.

      • Delivers timely and thorough analysis to support informed IT investment decisions.

Business Planning and Analysis (BPA)
  1. 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.

  2. All funding requests must be submitted as a proposal through the HP Project and Portfolio Management (HP-PPM) module within the Work Request Management System (WRMS). HP-PPM 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.

  3. Submissions must align to the Future State themes and the IRS IT Roadmap. If the proposal aligns to the Future State and the IRS IT Roadmap, then priority considerations would still be assigned. Given the current and future challenging budget climate, only submissions that align to Future State Themes and the IRS IT Roadmap will be considered.

  4. 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

  5. For additional guidance regarding the BPA Office and the Proposal Process, please access the Business Planning and Analysis website

Technical Support Office (TSO)
  1. 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.

  2. Coordinating, developing and maintaining Enterprise Service Desk level 2 support processes including; probe and response, assignment groups detail and ticket management.

  3. Providing subject matter expertise for the UWR process and the WRMS workflow configurations.

  4. Developing, coordinating, maintaining and distributing the UWR process and supporting procedures.

  5. Making changes to a work request based on the user reported issues via coordination efforts or incident/problem tickets.

  6. Leveraging the WRMS reporting for oversight of the end-to-end process of work requests

  7. Providing administration support for the WRMS module and process oversight including:

    1. The WRMS Compliance reporting support and execution for viewing, enterprise reporting and resolving issues identified.

    2. The WRMS Project and Portfolio Management (PPM) administration responsibilities (user administration, license management, configurations, etc.)

    3. The 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.

    4. Ownership and management of the WRMS CCB and Configuration Management.

  8. Providing trend analysis and metric reporting for work request processing.

  9. Providing oversight tracking and reporting on the work request process to organizational stakeholders and IRS senior and executive management.

  10. Monitoring the IT level end-to-end process, from submission to closure of a work request.

  11. Developing and publishing the WRMS training and communication products.

Work Request Support Office (WRSO)
  1. 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.

  2. Serves as the assigned Primary Coordinator for a work request when required.

  3. Provides subject matter expertise for the UWR process and the WRMS workflow configurations.

  4. Makes changes to a work request based on the user reported issues via coordination efforts or incident/problem tickets.

  5. Serves as a liaison between the requestor and IT supplier organizations for issues related to the UWR process and repository

  6. Develops, coordinates , maintains and distributes the UWR process and supporting procedures.

  7. Monitors the IT level end-to-end process, from submission to closure of a work request.

Primary Coordinator (IT)
  1. 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.

Supplier Organization (IT - ACIO)

  1. 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.

ACIO Coordinator (IT)

  1. 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 a 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 the 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.

ACIO Approver (IT)

  1. The IT ACIO Supplier Approver will have:

    • The authority to approve a work request response for their organization. The approving official will have the authority to allocate and commit resources in their organization. The approval represents the commitment by IT to deliver products and/or services reflected on the work request by the scheduled implementation date.

    • The authority to decide first if the work requests can be fulfilled, then ensuring accuracy of estimates for their organization. Estimates are calculated within the ICA Details Requests and summarized for the ACIO in the ICA Summary Request and validated and/or approved. For ACIO organizations, without a separate division approver, the ACIO approver may assume the role of the division/domain approver.

    • The ability to facilitate and/or escalate within current policy any work request decision if the ACIOs impacted are not in agreement for final disposition and response.

Supplier Division/Domain Coordinator (IT)

  1. 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.

Supplier Division/Domain Approver (IT)

  1. The division approver will be responsible for approving the estimates from their division on the ICA Detail Request. Estimates are rolled up to the ACIO coordinator in the ICA Summary Request which is approved by the ACIO Approver. For ACIO organizations without a separate division coordinator, the ACIO approver may assume this role.

Supplier Resource (IT)

  1. 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 the WRMS with any changes to assigned work requests.

    • Completing an approved or denied ICA Details Request with actual resources expended.

The WRMS Reporting

  1. Users can generate a variety of reports using the 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 the WRMS by the end user, as well as dashboards and search results. The WRMS will contain standard real-time dashboards containing information to be used to manage work requests for the following roles:

    • All WRMS users

    • Requestors

    • BSP Coordinators

    • ERB Coordinators

    • Primary Coordinators

    • ACIO Coordinators

    • Division/Domain Coordinators

    • Suppliers Resources

    • Executives and Compliance and Reporting Dashboards

  2. Each of the WRMS users 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.

  3. Additional specific searches can be saved at the user level to configure and provide the transparency to work request information as needed.

  4. Enterprise Reporting – Enterprise level reports have been defined and created. Details will be included in the WRMS Dashboards, Reporting, and Frequently Used Searches supplement to the WRMS User Guide.

Work Request Submission (Registering IT Demand)

  1. 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.

Work Request IT Review and Decision (Evaluation)

  1. 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:

      1. Returned for more information,

      2. Approved for delivery/implementation,

      3. Adjusted to update the time frame for delivery, or

      4. Determined as having no impact, or

      5. Denied

  2. 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 an Image: 38167015.gif

    Please click here for the text description of the image.

Work Request Types

  1. The Work Request Types are:

    1. Enhancement - Improvement work which enhances the current production environment (CPE). All Enhancement WRs will be subjected to the IRM 2.22.1.6.5.
      Subject 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


      Funding for all enhancement work shall be provided by IT above-core allocations and considered above-core work. The Chief Technology Officer or his designee shall make the final determination of an above-core enhancement work request should the IT supplier organization(s) and the business and functional operating divisions be unable to reach consensus.

      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 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.

    2. Legislative - Request to register demand for disposition for IT products and/or services to support an enacted legislative action.

    3. Sustaining Infrastructure (Rust) - Demand request for IT products and/or services to replace existing outdated assets as determined by IT policy to meet SLAs.

    4. 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).

The WRMS Functional Work Request Flow

  1. The WRMS is the authoritative, centralized repository for work requests. The WRMS can be accessed through the WRMS Database link or the WRMS Home Page. The WRMS maintains, distributes, and tracks work requests and associated documentation, attachments and responses. The WRMS is also a management and reporting tool.

  2. The flow of work request processing within the 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.

  3. 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.

  4. Estimates and approvals flow back up through this chain as do actual cost and resource figures, once the work has been completed. The 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.

Work Request Submission

  1. The requestor submits a work request that was approved by their organization for submission to IT.

  2. Any request still in draft stage may be withdrawn or deleted by the requestor.

BSP Coordination

  1. 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.

ERB Coordination

  1. 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.

Work Request Primary Coordination

  1. 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 can not be determined, a request will be sent to all ACIO coordination groups for analysis.

    • For Enhancement WRs the assigned Primary Coordinator will facilitate the Enterprise Intake Process and review by the Enterprise Intake Group.

    • 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:

      1. Request more information via the WRMS to the requestor, or

      2. 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.

Enterprise Intake (EI) Process

  1. 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), DME and Budget Cycle (Pre-Select) Investments Proposals 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. All Enhancement WRs will be subjected to the EI process.

  2. While the New Ideas, TEOAF, DME, and Budget Cycle Pre-Select 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.

  3. Please reference the Enterprise Intake Process for a more detailed description of this process.

Work Request ACIO Coordination

  1. 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.

  2. 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.

  3. 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.

  4. 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..

  5. If appropriate, the ACIO Coordinator can:

    • Deny the request with the appropriate justification

    • or Respond as no impact

  6. 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.

  7. In the event the ICA Details responses are not in agreement, the ACIO coordinator will use an internal process to secure a consolidated decision regarding the ACIO commitment to delivering the product or service.

Work Request ACIO Division/Domain Coordination

  1. 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:

      1. Request more information via the WRMS to the requestor, or

      2. Request an extension to the response due date, or

      3. 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.

Work Request IT Supplier Resource Analysis

  1. Upon assignment of an ICA Details Request, the Supplier Resource will review the request and all associated request 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:

      1. 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

      2. Contact the Requestor informally by phone or E-mail outside of WRMS, or

      3. Recommend Denial in the comments field for the Division Approver to review and concur.

    • The Supplier Resource will be required to update the ICA Details Request once the designated IT product/service is implemented.

    • The actual costs, implementation date and resource expenditures need to be entered and the work request completed.

    • The Supplier Resource will be required to update the ICA Details Request with actual costs and hours that are expended for requests that are denied.

Work Request Notifications

  1. The WRMS User Guide will outline the details for notifications. Notification will be sent for: status changes to all impacted users and roles during the processing of the work requests, and for certain conditions, for example: reminders for action.

Work Request Statuses

  1. 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.

Work Request- Parent Request (e.g., Legislative, Operations and Maintenance (O&M), RUST replacement, Enhancement)

  1. 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 This execution step forces the request look ahead to force certain fields by looking at the next status before returning from sub-workflow. The BSP Coordinator must enter notes and a denied reason, if the request is Denied.
    SYS - BSP Need More Information This execution step forces the request look ahead to force certain fields by looking at the next status before returning from sub-workflow. The Requesting Organization Approver must re-approve the request when the request is sent for more information.
    SYS - BSP Approved 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.
    SYS-Requestor Review Used to drive status changes

ICA Summary Request (opened for each impacted ACIO)

  1. 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 and, if it is the final ICA Summary, then it moves the WR to Post Implementation Review.
    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 can not be set as Not Impacted.
    Cancelled Work Request was cancelled; therefore the ICA Summary is Cancelled.

ICA Details Request (assigned to Supplier Resource)

  1. 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.

Work Request Standards

  1. 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.

  2. Submission of an approved work request represents the formal notification to IT that a product or service is needed.

  3. A work request must include a requested implementation date.

  4. 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.

  5. 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.

    In brief the procedure for escalating a denied work request is as follows:

    • The requestor determines to escalate a work request that has been denied.

    • The requestor prepares a business impact assessment and submits the escalation in WRMS.

    • The Primary Coordinator prepares an “escalation package” and refers the escalation to the manager level.

    • Facilitation between requestor and IT suppliers is performed.

    • The denial escalation is further escalated to director and ACIO levels as needed.

    • Final disposition of the work request is established and documented in WRMS.

    Additional information regarding the Escalation Process can be located below in IRM 2.22.1.102.22.1.10 Escalating a Denied Work Request

  6. A work request will contain a single requested implementation date and set of requirements.

    1. 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.

    2. 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.

  7. 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 theWRMS 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.

  8. 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.

  9. All work requests will require a business priority as follows:

    1. Low – Requests that have been submitted but are lower in priority for fulfillment, or

    2. Normal – Request submitted timely for consideration in the designated time frames, or

    3. 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

    4. 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).

  10. 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.

  11. 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.

  12. The IT resource supplier must record the work request actual costs and resources within 30 days of implementation and/or delivery.

  13. When IT denies a WR they will provide a reason for denial.

  14. 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

  15. 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.

  16. 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 (email, contact memoranda, or meeting minutes), are to be recorded or attached/linked to the work request.

  17. 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:

      1. Insufficient Requirements, or

      2. Missing Late Submission Approval, or

      3. Missing Mandatory Documents, or

      4. Clarification Required, or

      5. Other.

Escalating a Denied Work Request

  1. This section describes the process for escalating a WR.

Initiating the Escalation

  1. In the WRMS, a denial escalation is initiated by the requestor selecting to escalate a work request that has been returned as denied. The requestor must also:

    1. 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 WRMS.

    2. 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.

    3. Initiate the escalation in WRMS (See the WRMS User’s Guide for details).

BPRM Manager Level Escalation

  1. A requestor escalation of a denied work request generates a notification to BPRM support personnel. The assumption is that the Primary Coordinator assigned to the work request has already confirmed the consolidated denial of the request. The requesting organization escalates to ask IT for reconsideration and may result in trading off scheduled work in order to accommodate the delivery of the request. These negotiations need to be considered at the organization level for both the requestor and suppliers. BPRM takes the following steps:

    1. Preparing the escalation package

      The Primary Coordinator packages together all information related to the work request and its escalation and forwards it to the BPRM Escalation Group. This escalation package will also be forwarded to other directors, some of whom may not have access to WRMS and who also will require an overall summary of the work request as it stands. Any ICA Details, ICA Summaries and the work request from WRMS are incorporated in a PDF file, along with the requestor’s justification for escalation. Any pertinent attachments are incorporated in zip files named by the work request or ICA Summary or Detail number it relates to, and these are in turn incorporated into a single package of information regarding the request.

    2. Assigning an Escalation Group Designee

      The work request denial escalation goes to the BPRM Escalation Group, which designates who in the group will facilitate disposition of the escalation.

    3. Performing an Initial Review of the Denial Escalation

      The Escalation Group designee reviews the escalation package, in particular the requestor’s escalation request, and confers with the Primary Coordinator as needed. If there is any missing or incomplete information in the escalation request, the Escalation Group designee will email the requestor, BSP representative/designee and the Primary Coordinator, referencing the missing information that is needed to process the escalation request. The requestor is instructed to include the additional information in the work request notes or, if necessary due to length, as an attachment. The Primary Coordinator logs this request for additional information in the work request notes, along with the date.

      Rule: Time limit for requestor response to request additional escalation justification information:

      If the requestor designee fails to provide the additional denial escalation justification and impact information requested by the Escalation Group designee within 30 calendar days, the Primary Coordinator confirms the denial of the work request in WRMS. (Once this step is done, further escalation is not possible in WRMS and the request is closed.)

    4. Conferring with supplier and requestor managers

      The Escalation Group designee adds any further summary observations to the escalation package as appropriate.
      The Escalation Group designee contacts the corresponding requestor BSP representative/designee and IT supplier managers in each of the impacted ACIOs, or their designees, and forwards the escalation package for their review.
      The BPRM Escalation Group designee facilitates a consensus disposition of the work request with the requestor BSP representative/designee and supplier managers/designees. This may be done by conference call or direct meeting. The Primary Coordinator acts as scribe for these meetings.

      Rule:Time limit for supplier and requestor manager collaboration on a denial escalation:
      If the BPRM Escalation Group designee cannot establish a consensus response among supplier managers/designees and the requestor BSP representative/designee within 30 calendar days, the issue is escalated to the director level.

    5. Establishing a supplier and requestor manager level disposition
      The possible outcomes of this supplier and requestor manager collaboration are:
      Approval.

      The supplier managers/designees and requestor BSP representative/designee conclude that the work request can be approved. Adjusting ICA Details and Summaries may be required to achieve this disposition. These determinations, as documented by the Primary Coordinator, are passed back down by managers within each ACIO to the ACIO coordinators, and are incorporated in the work request notes by the Primary Coordinator. The Primary Coordinator rejects the work request denial in WRMS, and approves the work request once any adjustment of ICA Summaries is completed. (See the WRMS User’s Guide for details on how this is accomplished).
      Denial.

      The supplier managers/designees and requestor BSP representative/designee reach a consensus conclusion that the work request denial should be upheld. The Primary Coordinator documents the consensus conclusion and incorporates the consensus disposition into work request notes and attachments as appropriate. The Primary Coordinator then finalizes the denial in WRMS (See the WRMS User’s Guide for details).
      Lack of consensus.
      The supplier managers/designees and requestor BSP representative/designee are unable to reach consensus within an acceptable timeframe (see rule above). In this case the work request disposition is escalated to the director level.

Director Level Escalation

  1. Updating the escalation package

    • The Primary Coordinator updates the escalation package with a brief summary of the outcome of the meeting and forwards it to the BPRM Manager.

    • The BPRM Manager reviews the package as appropriate for presentation to the BPRM/Enterprise Intake Director.

    • The BPRM Manager provides the material to and reviews it with the BPRM/Enterprise Intake Director.

  2. Conferring with ACIO directors and requestor directors

    • After reviewing the escalation package, the BPRM/Enterprise Intake Director contacts counterpart director level executives in the Requestor Organization and each of the impacted ACIOs, sharing the consolidated escalation package provided by the BPRM Manager.

    • The BPRM/Enterprise Intake Director facilitates a consensus disposition with this group.

  3. Establishing a director level disposition

    The possible outcomes of this ACIO director level collaboration are:

    • Approval The ACIO directors and Requestor director conclude that the Work Request can be approved. This will require new ICA Details and Summaries to achieve this disposition. These determinations, as documented by the Primary Coordinator, are passed back down by managers within each ACIO to the ACIO Coordinators, and are incorporated in the Work Request notes by the Primary Coordinator. In WRMS, the Primary Coordinator initiates the re-evaluation of the Work Request and creates new ICA Summaries for approval. (See the WRMS User Guide for details on how this is accomplished).

    • Denial The ACIO directors and requestor director reach a consensus conclusion that the work request denial should stand. The consensus conclusion is documented by BPRM, reviewed with stakeholder executives and incorporated in the work request notes by the Primary Coordinator. The Primary Coordinator confirms the work request denial in WRMS (See the WRMS User Guide for details).

    • Lack of consensus The ACIO directors and requestor director are unable to reach consensus within a time frame deemed reasonable by the BPRM Director. In this case the work request disposition is escalated to the ACIO for Strategy and Planning (ACIO S&P) for disposition with the impacted ACIOs and the requesting organization’s executive. The WRSO Chief consolidates and packages the current work request status for the BPRM Director who forwards this to the S&P ACIO.

ACIO Level Disposition

  1. The ACIO S&P facilitates a disposition of the work request denial escalation with the impacted ACIOs and requesting organization executive, with support from the BPRM Director as needed.

  2. Once the work request is dispositioned – approved, approved with modifications, or denial confirmed – BPRM facilitates summarization of the findings and updates to the work request.

Response Due Date (RDD) Extension

  1. This section describes the enterprise-wide standard process for requesting and recording a disposition for extensions to the RDD on a work request.

  2. Any 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 can not 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 the WRMS 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.

Procedure for requesting RDD extensions

  1. 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.

  2. After validating that all the required information has been provided, the supplier division coordinator forwards the request to the primary coordinator.

  3. 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:

    1. Return the request for more complete justification, or

    2. Approve the extension request immediately and notify the requestor, or

    3. Notify the requestor and facilitate a disposition between the supplier and requestor.

  4. Once the extension is approved, the Primary Coordinator updates the RDD in WRMS, and notifies the requestor that this has been done.

Requesting a Response Due Date Extension

  1. 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.

  2. The first step, before formally requesting an RDD extension in WRMS, 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 within WRMS. WRMS is a tool for tracking work requests and facilitating work flow; it is not a substitute for communication and collaboration between supplier and requestor.

  3. Once the matter has been discussed between supplier and requestor, the supplier resource must, within WRMS, 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:

    1. the reason(s) why the RDD extension is needed,

    2. the impact on the organization if it is not granted,

    3. the proposed RDD extension - number of calendar days beyond the current RDD, and.

    4. the rationale for the number of additional calendar days requested.

    1. See the WRMS User’s Guide for details on how this is accomplished within 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.

      1. 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.

        1. 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.

Forwarding the Response Due Date Extension

  1. When the Supplier Resource Returns the ICA Detail and escalation request in WRMS to the supplier division coordinator, the supplier division coordinator:

    1. 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).

    2. Selects Extension Required in WRMS. This formally logs the extension request in WRMS and forwards the extension request to the work request Primary Coordinator.

Accepting the Response Due Date Extension

  1. Upon receiving a request for an RDD extension the Primary Coordinator will:

    1. 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 in WRMS on what information is required or what rules need to be met. The primary coordinator also sends an email to the supplier ACIO coordinator, notifying them that the request for extension has been returned to the supplier division coordinator.

    2. 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 email (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 email. 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 email 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.”

    3. 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 WRMS and enters the updated RDD as described above.

    4. 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.

    5. 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.

Exception - Specifying an Extended RDD on a submitted work request

  1. 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:

    1. 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.

    2. 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.

  2. 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.

WRMS IRM - Figure 1 Work Request Management System Process Overview

This is an Image: 38167067.gif

Please click here for the text description of the image.

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.
BODS/FODS Business Operating Divisions / Functional Operating Divisions, also known as the requestors
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 proposals are 1-year requests for small projects, such as minor system enhancements, requests for software licenses or new hardware, etc. If proposal scope is larger and is a multi-year effort, then the request should go through Pre-Select processing instead.
Dispatchers Receive requests, identifies and name assigns individual Coordinators.
Drafts Drafts are saved not-submitted requests
EIG Enterprise Intake Group - Reviews Enhancement WRs and provides recommendations for the ERT.
EPO Estimation Program Office
ERB Engineering Review Board
Future State themes Formerly Concept of Operations (ConOps). Logically group work (and funding requests) into organized groups of similar or related work efforts based on the IRS Future State vision.
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 he WR business needs. The WRSO acts as the IC.
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.
Notification WRMS will send an email 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.
PPAC Planning, Programming and Audit Coordination
Primary Coordinator The Primary Coordinator resides within a 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.
Request Types 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 email to review the request before it is submitted.
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
Workflow A workflow consists of a logical series of steps that define a process from beginning to end. Workflow is 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
WRMS Work Request Management System – based on HP PPM software, an ITIL-based product for managing demand requests for IT products and services
WRSO Work Request Support Office