2.22.1  Unified Work Request (UWR) Process

Manual Transmittal

September 11, 2012

Purpose

(1) This transmits revised Internal Revenue Manual (IRM) 2.22.1, Requirements and Demand Management, Unified Work Request (UWR) Process, previously titled Requirements Management, Demand Management, UWR Process.

Material Changes

(1) The definitions for some of the work request workflows have been revised.

(2) The process for escalating a work request has been updated.

(3) The graphic file has been revised.

(4) All references to requirements have been modified for clarity.

Effect on Other Documents

IRM 2.22.1, dated October 7, 2011, is superseded.

Audience

This IRM applies to all Internal Revenue Service (IRS), Treasury organizations and other official affiliates requesting or providing IT products and services from (IT).

Effective Date

(09-11-2012)

Terence V. Milholland
Chief Technology Officer

2.22.1.1  (09-11-2012)
Introduction

  1. IT is committed to increasing customer satisfaction through effective registration and efficient response to demand for Information Technology (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 RADM 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 cost and schedule for the implementation and/or delivery of any agreed upon IT products or services.

  2. Additionally, the RADM 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 (https://ol5081.enterprise.irs.gov/).

  3. The WRMS provides a predefined selection of workflows for different work request types and supplier based impact cost analysis workflows. This design allows end-to-end management of registered demand from initial request through IT evaluation, analysis, disposition and work planning.

  4. Training is 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 RADM WRMS website at http://mits.web.irs.gov/SP/RADM/WRMS/default.html.

2.22.1.1.1  (10-01-2010)
Purpose of the UWR IRM

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

2.22.1.1.2  (10-01-2010)
Scope of the UWR IRM

  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.

2.22.1.1.3  (10-01-2010)
Distribution of the UWR IRM

  1. This IRM is available through the RADM WRMS web site at http://mits.web.irs.gov/SP/RADM/WRMS/default.html and the IRS IRM web site at http://publish.no.irs.gov.

2.22.1.2  (06-29-2012)
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 a 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. 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.

    • Normal - Requests submitted timely for consideration in the designated timeframes.

    • High - Requesting organization is requiring implementation in less then 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).

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

    • Human resources

    • Other IT services beyond the scope of tickets for break/fix and GetIT requests for service

    • Software/Infrastructure changes for IRS systems

  4. A IT organization is considered a requestor organization when requesting support/resources from another IT organization. In addition to the systemic notifications generated during the processing of a work request, constant communication and coordination with the requestor of each work request during processing within IT is required. As a service, IT's representatives will, at a minimum, contact the requestor whenever a work request response or delivery date is changed. Adherence to this policy to gain concurrence on date changes is essential to building and maintaining customer confidence in IT's ability to provide quality end-to-end service. Extending a scheduled response or delivery date may cause a negative impact on the requesting organization and increase escalated work requests impeding planning and efficiency.

2.22.1.3  (10-01-2010)
UWR Process Roles and Responsibilities

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

2.22.1.3.1  (06-29-2012)
Requestor Organization (Business or Functional Operating Divisions including IT)

  1. Any business or functional operating division 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 Business Systems Planning (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 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 Coordination (WRC) Office in RADM for assistance, if a contact cannot be identified.

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

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

2.22.1.3.2  (06-29-2012)
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. Coordination is strongly encouraged because it is a critical activity in the work request submission process and can improve the quality of the requirements. 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 on the RADM WRMS website at http://mits.web.irs.gov/SP/RADM/WRMS/userguide.htm 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, 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.) RADM 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.

      The Work Request types are:

      1. Generic - Request to register demand for disposition for IT products and/or services. Generic is used only when all others don’t apply.

      2. Enhancement - Improvement work which enhances the current production environment (CPE). 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 Service Level Agreements (SLAs);

        4. Contain 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); 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 (O&M).

          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.

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

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

      5. Sustaining Infrastructure (O&M) Work Request - Demand request for IT products and/or services to maintain current operating levels (O&M).

      6. Judicial - Request to register demand for disposition for IT products and/or services to support a judicial opinion.

    • 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, processes, business rule sets, or business rules from a RADM requirements repository, and/or references needed to support the work request requirements.

    • Identifying the IT points of contacts, if known.

    • Identifying impacted organizations, if known.

    • 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 RADM WRMS website at http://mits.web.irs.gov/SP/RADM/WRMS/default.html. Please consult the UWR, WRMS Guidance and Procedures Handbook, RADM UWR SOP #003 - Requesting & Entering a Disposition for a Response Due Date (RDD) Extension.

    • Providing feedback on the work request experience upon completion of the request.

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

    • Providing feedback on approved and completed work requests.

    • 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 RADM 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 RADM WRMS website http://mits.web.irs.gov/SP/RADM/WRMS/default.html.

2.22.1.3.3  (10-21-2011)
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, 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.

2.22.1.3.4  (06-29-2012)
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, 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.

2.22.1.3.5  (06-29-2012)
IT Support Organizations (Coordinators and Suppliers)

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

2.22.1.3.6  (06-29-2012)
Requirement and Demand Management Staff

  1. The RADM organization is the process owner of the Unified Work Request process. The primary staff supporting the process includes, but is not limited to the WRC Office, Tools Management and the WRMS Support Staff. The RADM Staff responsibilities include (but are not limited to):

    • Being members of the work request Primary Coordinator group queue. Members of this coordination group receive notification of every new work request submitted and ready for name assignment to a specific Primary Coordinator for processing.

    • Serving as the assigned Primary Coordinator for a work request when required.

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

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

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

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

    • Resolving issues and incidents reported via the break/fix ticket process. This includes supporting issues at the individual work request and workflow level, reporting issues, configuration issues, etc.

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

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

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

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

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

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

    • Developing and publishing the WRMS training and communication products.

2.22.1.3.7  (06-29-2012)
Primary Coordinator (IT)

  1. 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 (WRC) in the RADM 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.

    • Monitoring the work request to ensure that a response has been received or an extension has been approved and documented in the work request within 90 calendar days of the requesting organization's approval of the work request.

    • Monitoring the work request to ensure that the request is moving forward and has not stalled.

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

2.22.1.3.8  (06-29-2012)
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, processes, business rule sets, or business rules with the requestor, and responding appropriately.

    • Delivering IT products and services that satisfy work request requirements if resources (i.e., staff, budget, infrastructure, etc.) are available or providing justification for denying a request.

    • Designating organizational level ACIO coordinators, Division/Domain coordinators and Supplier Resources to receive, control, evaluate and respond on work requests for their products and services.

    • Establishing and maintaining internal policies for the review and clearance of work request in accordance with this IRM.

    • Considering available resources, workload, strategic plans, and budget to determine the implementation date on approved requests.

    • Providing justification to the requesting organization when a work request is denied and recording any expended costs within the work request.

    • Preparing a response or determining a new response due date within 90 calendar days of the requesting organization’s approval of the work request.

2.22.1.3.9  (06-29-2012)
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.

      Note:

      Upon initial implementation - Only Applications Development (AD) and Enterprise Operations (EOPS) will have a division/domain level queue for assignment. Supplier ACIO Coordinators for AD and EOPS will assign the ICA Details Request to a Supplier Division Coordinator. Supplier ACIO Coordinators for all other ACIOs will perform the function of Supplier Division

    • Providing approval and completing a consolidated response (dates, cost, etc.) on the ACIO ICA Summary Request(s).

    • Monitoring requests in progress within the ACIO according to established internal ACIO and IT-wide policies and procedures (late responses, no activity, escalation, etc.).

    • Coordinating across the IT ACIO divisions on integrated services and engaging requestors and/or request approvers, as needed during the process.

    • Generating reports and maintaining oversight of the process within their ACIO organization.

2.22.1.3.10  (06-29-2012)
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.

2.22.1.3.11  (06-29-2012)
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.

2.22.1.3.12  (06-29-2012)
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.

2.22.1.3.13  (10-21-2011)
Supplier Resource

  1. The Supplier Resource(s) responsibilities will include:

    • Compiling and entering estimated cost and effort information in consideration of the attached high-level requirements/business needs, 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.

2.22.1.3.14  (10-01-2010)
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

    • 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 RADM WRMS website at http://mits.web.irs.gov/SP/RADM/WRMS/default.html from the User Guide tab.

  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 – (TBD) Enterprise level reports will be defined and created and will include defining the RADM support responsibilities. Details will be included in the WRMS user guide. Reporting will support the work request end-to-end process monitoring.

  5. UWR process and the WRMS measures will be developed after initial deployment following the measures process for data dictionary development and executive approvals.

2.22.1.4  (06-29-2012)
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 coordinated as needed for complete high-level requirements/business needs, 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 includes:

    • Identification and documentation of business requirements priority (see http://mits.web.irs.gov/brrm/index.htm for requirements guidance), business justification and determining the work request type.

    • Preparation and submission of the work request.

    • Coordination of the work request with potentially impacted parties is strongly encouraged, including other requestors and/or suppliers for additional data and requirements specifications.

    • Coordination of the work request with the WRC Office in RADM, 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.

2.22.1.5  (06-29-2012)
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, 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.

    Exhibit 2.22.1-1.

2.22.1.6  (10-01-2010)
The WRMS Functional Work Request Flow

  1. The WRMS is the authoritative, centralized repository for work requests. The WRMS can be accessed through http://mits.web.irs.gov/SP/RADM/WRMS/default.html or the RADM website at http://mits.web.irs.gov/SP/RADM/. 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.

2.22.1.6.1  (06-29-2012)
Work Request Submission

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

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

2.22.1.6.2  (06-29-2012)
Work Request Primary Coordination

  1. Once approved by the requesting organization, 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.

    • 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 RADM UWR SOP #004 - Resolving Conflicting ICA Summaries for additional guidance.

2.22.1.6.3  (10-01-2010)
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.

2.22.1.6.4  (10-01-2010)
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:

    • During the initial deployment of the WRMS, only Applications Development and Enterprise Operations will have division/domain level coordinators. All other organizations will use the ACIO coordinators to fulfill the role of a division/domain coordinator.

    • 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

      2. Request an extension to the response due date

      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.

2.22.1.6.5  (06-29-2012)
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, 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 email 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.

2.22.1.6.6  (10-01-2010)
Feedback

  1. The WRMS will notify the requestor via email to provide feedback on completed work requests before the systemic closure of the request. The feedback provides the customer the opportunity to critique the UWR process and the WRMS. If the feedback request is not completed within 30 days of notification the request will be systemically closed.

2.22.1.7  (10-01-2010)
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

    • Certain conditions, for example: reminders for action.

2.22.1.8  (10-01-2010)
Work Request Statuses

  1. The following is section list of the status codes displayed on the request types as it is processed end-to-end. The tables below may be changed as workflow steps are updated. It is important to note that there are status dependencies between the parent work request and the supporting child ICA Requests (i.e. Work request to the ICA Summary Request, ICA Summary Request to the ICA Details Request.) Some status changes on the parent work request will be driven by the processing of the child request.

2.22.1.8.1  (06-29-2012)
Work Request- Parent Request (e.g., Generic, Legislative, Judicial, Operations and Maintenance (O&M), RUST replacement, Enhancement)

  1. The following section contains a table of status codes 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.
    Pending More Information Returned to requestor for more information.
    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 Impact Cost Analysis Request 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.
    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 Post Implementation Review Suppliers have updated request to show that work has been completed. Waiting for requestor to respond to feedback questions.
    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.

2.22.1.8.2  (10-01-2010)
ICA Summary Request (opened for each impacted ACIO)

  1. The following table depicts status values for the work 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.
    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 Step where the ICA Details are created from the ICA Summary workflow.
    Pending Impact Cost Analysis The assigned Supplier Resource(s) conducts impact cost analysis on the ICA Details.
    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 sit 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.
    Denied ICA Summary is denied by Supplier ACIO Approver.
    Not Impacted Supplier is not impacted by work request.

2.22.1.8.3  (10-01-2010)
ICA Details Request (assigned to Supplier Resource)

  1. The following table depicts status values for the work 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 sit 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.
    Assigned Used to force status dependencies. This will enable the request to continue through the workflow.
    Complete Consolidates all the Estimated Implementation Dates in the Estimated Cost and Effort Details table component and takes the greatest date and auto-populates the Scheduled Implementation Date on the ICA.

2.22.1.9  (06-29-2012)
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. 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

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

  6. 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 at http://mits.web.irs.gov/SP/RADM/WRMS/library.htm. 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.

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

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

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

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

    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.

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

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

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

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

  12. The requestor will have 30 days to respond to post implementation review feedback questions on any delivered work request prior to its final closure. The feedback provides the customer the opportunity to critique the UWR process and the WRMS. If the feedback request is not completed within 30 days of notification the request will be systemically closed.

  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. Denied requests cannot be re-opened. 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, 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

      2. Missing Late Submission Approval

      3. Missing Mandatory Documents

      4. Clarification Required

      5. Other

2.22.1.10  (10-01-2010)
Escalating a Denied Work Request

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

2.22.1.10.1  (06-29-2012)
Initiating the Escalation

  1. In the Work Request Management System (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 complete the following:

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

2.22.1.10.2  (06-29-2012)
RADM Manager Level Escalation

  1. A requestor escalation of a denied work request generates a notification to RADM 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. RADM 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 RADM 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 RADM 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 RADM 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 RADM 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. This may require adjusting 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. 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.

2.22.1.10.3  (10-01-2010)
Director Level Escalation

  1. Updating the escalation package

    • The Primary Coordinator updates the escalation package with session minutes and forwards it to the WRC Chief.

    • The WRC Chief reviews, organizes, consolidates and summarizes the package as appropriate for presentation to the RADM Director.

    • The WRC Chief provides the material to and reviews it with the RADM Director.

  2. Conferring with ACIO directors and requestor directors

    • After reviewing the escalation package, the RADM Director contacts counterpart director level executives in the requestor organization and each of the impacted ACIOs, sharing the consolidated escalation package provided by the WRC Chief.

    • The RADM 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 may require adjusting ICA Detail and summaries to achieve this disposition. (See the WRMS User’s Guide for details on how this is accomplished). These determinations are documented by RADM and are passed back down by managers within each ACIO to the ACIO coordinators. In WRMS, the Primary Coordinator incorporates the disposition notes and rejects the work request denial (see the WRMS User Guide for details) putting the work request back into the workflow process. Once ICA Summaries and Details are completed as per the agreed upon disposition, the Primary Coordinator approves the work request in WRMS.

    • Denial The ACIO directors and requestor director reach a consensus conclusion that the work request denial should stand. The consensus conclusion is documented by RADM, 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 Users 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 RADM 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 WRC Chief consolidates and packages the current work request status for the RADM Director who forwards this to the S&P ACIO.

2.22.1.10.4  (10-01-2010)
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 RADM Director as needed.

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

2.22.1.11  (06-29-2012)
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 RADM UWR SOP #003 - Requesting & Entering a Disposition for a Response Due Date (RDD) Extension and RADM 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 RADM WRMS website at http://mits.web.irs.gov/SP/RADM/WRMS/default.html.

2.22.1.11.1  (10-21-2011)
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 RADM 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.

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

    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.

2.22.1.11.2  (10-21-2011)
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. Reason(s) why the RDD extension is needed

    2. Impact on the organization if it is not granted

    3. Proposed RDD extension - number of calendar days beyond the current RDD

    4. Rationale for the number of additional calendar days requested

      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

      1. Notes must be attached with new justification, including all points 1-4 noted above in paragraph (3).

      2. The notes must also include certification of approval by the supplier ACIO approver or his/her designee must be included.

        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:

        1. Notes must be attached with new justification, including all points 1-4 noted above

        2. The notes must also include certification of approval by the supplier ACIO.

          Response Due Extensions that exceed the Requester Implementation Date will need additional coordination with the requestor. If this is problematic for the requestor the issue will need to be elevated in the same escalation as a denied request and an impact statement from the requestor is needed.

2.22.1.11.3  (10-21-2011)
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.

2.22.1.11.4  (10-21-2011)
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 RADM WRMS website at http://mits.web.irs.gov/SP/RADM/WRMS/default.html.

    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.

2.22.1.11.5  (06-29-2012)
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 work a 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.

Exhibit 2.22.1-1 
WRMS IRM - Figure 1 Work Request Management System Process Overview

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

More Internal Revenue Manual