1.55.7  Wage and Investment Research and Analysis (WIRA) Procedural Guidelines

Manual Transmittal

August 30, 2012

Purpose

(1) This transmits new IRM 1.55.7, Wage and Investment Research and Analysis (WIRA) Procedural Guidelines.

Material Changes

(1) This is a new IRM. It outlines the directions that guide WIRA senior managers and researchers through the steps that are necessary to complete research for our customers.

Effect on Other Documents

None

Audience

Wage and Investment Research and Analysis

Effective Date

(08-30-2012)

Frederick T. McElligott
Director, Research and Analysis
Wage and Investment Division

1.55.7.1  (08-30-2012)
Procedural Guidelines Overview

  1. The mission of Wage and Investment Research and Analysis (WIRA) is to inform valued operational change. For more information about the organization, see IRM 1.1.13, Wage and Investment..

  2. The WIRA Procedural Guidelines govern the way WIRA does business. Each procedure addresses a specific area of concern for WIRA researchers and senior managers. The procedural guidelines include the following:

    • The WIRA Approach

    • Project Lifecycle

    • Quality Assurance

    • Data Retention and Security

    • Survey Contract Administration

    • Administrative Responsibilities

1.55.7.2  (08-30-2012)
The WIRA Approach

  1. The WIRA Approach is designed to ensure that WIRA researchers deliver high quality products resulting in valued operational change.

  2. The three key components underlying the WIRA Approach to conducting research are:

    1. Know your customers' business

    2. Understand the business of research

    3. Follow core operational processes and procedures

1.55.7.2.1  (08-30-2012)
Know Your Customers' Business

  1. Why is it important to know your customers' business? It is essential to:

    • Conduct effective research for the customer.

    • Inform decisions about how to conduct the research.

    • Put the research project into the proper business context.

    • Ensure that the research findings and conclusions are relevant to your customer's operations.

    • Define a timely deliverable.

    • Determine the most effective presentation of the deliverable.

    • Contribute to WIRA's role as a consultative partner, rather than a research vendor.

    • Exceed customer expectations.

  2. How do you get to know your customers and remain knowledgeable about them?

    • Be proactive to develop productive customer relationships.

    • Establish formal periodic meetings to discuss current and prospective research projects.

    • Become familiar with the IRS Strategic Plan and Wage and Investment (W&I) Operations Plan.

    • Review your customer's Concept of Operations (CONOPS), mission statement, strategic goals, operational objectives, and performance measures.

    • Review your customer’s operational and business performance review documents.

    • Understand key trends and results from Customer Satisfaction Surveys.

    • Understand and analyze your customer’s performance measures and trends.

    • Regularly review your customer’s web site.

    • Attend your customer’s Continuing Professional Education (CPE) when allowable.

    • Visit field locations to observe operational processes and talk to front line staff, if applicable.

  3. Knowing your customers is an ongoing process. The success of the WIRA Approach requires you to understand your customer’s operational needs, priorities, and objectives.

1.55.7.2.2  (08-30-2012)
Understand the Business of Research

  1. What does it mean to understand the business of research? It means that you should:

    • Know current trends in research methods and practices within your field.

    • Understand data availability, benefits, limitations of usage, and relevance of research methods to business objectives.

  2. Why is it important to understand the business of research? It will:

    • Allow you to apply the technical skills and judgment necessary to define the relevant business questions and research outcomes.

    • Help you to choose and develop research and analytical methods that are consistent with best practices within the larger research community. This helps you provide an accurate and valued answer to the business question(s).

1.55.7.2.3  (08-30-2012)
Follow Core Operational Processes and Procedures

  1. The following processes and procedures have been put in place in order to conduct research that informs valued operational change:

    1. Project Lifecycle -- a uniform set of procedures for project assessment, planning, data gathering, data analysis, communication of results, and post-research tasks.

    2. Quality Assurance -- a collection of related activities that guide WIRA senior managers and researchers through the preparation of a high quality and accurate deliverable.

1.55.7.2.4  (08-30-2012)
Adhere to Prerequisites to Conduct WIRA Research Projects

  1. In order to follow the procedures outlined in the WIRA Approach, WIRA researchers and senior managers must be familiar with the following:

    • Project Types

    • Project Initiation Methods

    • Project Management System

1.55.7.2.4.1  (08-30-2012)
Project Types

  1. WIRA projects fall into one of four types: Program, Standard, Ad Hoc, and Infrastructure. The procedures and required documentation differ for each project type and are described later in this manual. These project types are defined based on the complexity of the business challenges, the scope of required research, the timing of customer actions resulting from research findings, and the level of the operational consultation.

    Project Type Description
    Program A program consists of a series of iterative deliverables associated with a formal operational initiative. The initiative and attendant operational performance measures span an extended time period, often exceeding a year. While a milestone deliverable could be considered a standard project, success is dependent on the cumulative impact of the series of deliverables. A project with ongoing monthly or quarterly reports would be categorized as a Program.
    Standard Standard projects typically involve a specific, standalone, research initiative, which include, but are not limited to: profiles, surveys, predictive models, or experiments. Standard projects are generally characterized by significant operational implications, research complexity, extended research resources and time, and usually a limited number of analytic products. They are distinguished from Program initiatives by more restrictive scope, resource demands, and deliverables.
    Ad Hoc Ad Hoc projects are typically completed within a short period of time, usually less than a month. Ad Hoc projects include running data queries and creating maps, spreadsheets, charts, or tables. These may be the format for the final deliverable or may be accompanied by a very short narrative. Ad Hoc projects tend to be issue specific requiring a more concise, often data specific, answer.

    Note:

    Ad Hoc projects can also be consulting efforts where WIRA researchers perform a support role outside of WIRA. Researchers may be called upon to conduct data analysis, evaluate the appropriateness of chosen methods, or review operational or functional capabilities. The project lead is typically an individual within the requesting organization and the WIRA researcher serves as a contributing member of the team.

    Infrastructure Infrastructure projects include activities, such as development and maintenance of the project management system, customer satisfaction survey administration, training coordination, preparation of research job aids, in-house training, Sharepoint administration, and contract oversight.

1.55.7.2.4.2  (08-30-2012)
Project Initiation Methods

  1. The WIRA Approach requires that you engage in continuous dialogue with your customer and that you understand your customer’s current operational needs and priorities. Once you have a full understanding of these operational objectives, you must be proactive in working with the customer to discuss the prospective value of research. Discussions about potential projects can begin in several ways, including:

    Initiation Method Description
    Customer Initiated The customer initiates a discussion with a WIRA researcher, senior manager, or the WIRA Director concerning potential research. Upon receipt of the new project idea, designated WIRA employees explore to ensure that the idea meets the criteria for starting a new project, according to the project assessment guidelines in IRM 1.55.7.3.1, Project Lifecycle. If the idea does not meet the criteria, the customer is informed of the decision and provided an opportunity to amend the request.
    Program or Project Recommendations and Follow-up A new project idea can be initiated from recommendations from current program, recent projects, or follow-up meetings with a customer.
    Oversight Recommendation New project ideas can be initiated from an oversight recommendation from Treasury Inspector General for Tax Administration (TIGTA), Office of Management and Budget (OMB), Government Accountability Office (GAO), and National Taxpayer Advocate’s Most Serious Problems (MSPs).
    WIRA Employee Initiated WIRA employees can initiate a project idea based on their research knowledge and their understanding of the customer's needs, priorities, performance measures, and trends.

1.55.7.2.4.3  (08-30-2012)
Project Management System

  1. The project management system is used to manage WIRA's research and analytic projects. This system integrates project initiation, project planning, project updates, project status, project reports, and employee time reporting. Regardless of the platform or version of the system that is available to WIRA, you must consistently and accurately use this system to reduce project management time and burden. See IRM 1.55.7.7.1 Project Management System Usage for more information on the project management system.

1.55.7.3  (08-30-2012)
Project Lifecycle

  1. The WIRA project lifecycle consists of six steps: project assessment, project planning, data gathering, data analysis, communication of results, and post-research tasks.

  2. The type of project determines the number of research steps involved.

    • Program and Standard projects typically follow six general steps, regardless of the research type or method.

    • Ad Hoc projects generally follow highly condensed guidelines.

    • Infrastructure projects generally do not follow the project lifecycle steps since these projects typically support other research project types.

  3. Figure 1.55.7-1 (below) shows the WIRA project lifecycle.

    Figure 1.55.7-1

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

  4. These steps are described below.

1.55.7.3.1  (08-30-2012)
Step 1: Project Assessment

  1. During the Project Assessment phase, you must determine the answers to the following questions:

    • Rationale – Why address this business need/objective and why now? What is the scope of work required to effectively address this need?

    • Operational Change – What operational performance attribute will/could change as a result of the project? How will the customer use the research results?

    • Measure of Impact – What performance measures are affected? Is the business objective well defined? What analytic product or deliverable constitutes project success?

    • Comparative Value – Is customer prioritization based on the relative impact of the initiative? What are the customer expectations for the final product?

    • Time Frame for Results Delivery – What are the resource requirements? Can we deliver a product that meets or exceeds customer expectations? What is the time frame for delivery of results? What are the potential challenges and risks to meeting these expectations?

    • Scope and Interdependencies – Are the business and project objectives sufficiently defined to prevent scope expansion? What are the interdependencies, if any, between this project and other WIRA work?

  2. The project assessment stage of the project lifecycle involves discussing with the customer to determine what constitutes "project success" and whether WIRA can successfully meet that expectation. If WIRA cannot meet this expectation, the customer must be so informed.

  3. Until the project is approved, time expended for discussion of a potential project should be charged to the project planning time code.

1.55.7.3.1.1  (08-30-2012)
Research Project Dialogue

  1. WIRA employees must develop familiarity with their functional customer’s operations and priorities through direct and continual engagement. The focus of this engagement is to understand the function’s needs, operational objectives, and performance measures.

  2. Engagement can and will take many forms including:

    • Discussions with subject matter experts

    • Site visits

    • Related research

    • Understanding of operational procedures, performance measure definitions, and performance status

    • Familiarization with the W&I Operations Plan and related function guidance (e.g. Program Plan)

    • Any other related activity that helps to increase understanding of customer operational needs

  3. Discussions with functional analysts at this early stage are informal. They should facilitate dialogue about current and future operational needs that are supported by research projects. These discussions focus on exploring the question of “why?”, with the answer relating to a specific performance measure and business objective. If the answer does not relate to a specific performance measure and business objective, the project objective may require more clarity. It is critical at this point the WIRA researcher defines "project success" in terms of impact on specific performance measures and business objectives.

  4. During this discussion the WIRA researcher should ensure the customers understand that WIRA's definition of organizational value is directly related to WIRA's ability to meet their needs.

1.55.7.3.1.2  (08-30-2012)
Research Project Proposal

  1. The senior manager should ensure that the information obtained by the WIRA employee during the project dialogue phase is sufficiently complete, relevant, and clear to consider further project development.

  2. If the senior manager and customer agree that the potential research project warrants further development, the designated WIRA researcher must initiate the project in the project management system.

1.55.7.3.1.3  (08-30-2012)
Project Approval and Assignment

  1. The senior manager will review the information in the project management system to ensure that it is adequate for completing project approval and resource allocation assessments.

  2. The senior manager performs a capacity assessment by weighing the following aspects of the project:

    • Clarity of business objective and relationship to specific performance measure(s)

    • Comparative value of this project versus other potential research activities

    • Potential costs - Staff and non-staff

    • Time frame for delivery of results

    • Staff time and skills required

    • Customer priority

    • Benefits to WIRA (staff development, customer relations, etc.)

    • Benefits to customer/IRS (operational improvements, etc.)

  3. At the discretion of the WIRA Director, project proposal and approval discussions may include one or more WIRA senior managers. In addition to the Director and the senior manager(s), technical leads and WIRA's senior operations advisor may participate in these discussions. The purpose of such reviews is to discuss project approach, expected outcomes and, if relevant, required cross-functional support.

  4. All Program and Standard projects require approval by the WIRA Director. For all other project types, WIRA Director approval is based on project requirements. As a guide, any project meeting the following criteria must be brought to the WIRA Director's attention for approval:

    • Requires more than one month and more than 160 staff hours

    • Responds to W&I Senior Leadership or IRS oversight organization requests

    • Will cause delay in other existing projects

  5. All Program and Standard projects require approval from the customer's operational executive. This approval must be documented in the project prospectus.

  6. Once the project is approved by the WIRA Director and the customer's operational executive, the WIRA Director assigns it to a specific research group. The senior manager for that group then designates a project lead, as well as required staffing for the project. Staffing for the project team, may be drawn from different research groups.

  7. The project lead must generally complete the project prospectus on the project management system within 2 business days following approval to begin the project. The prospectus must be completed to the greatest extent possible based on current information. It is expected that some information may be incomplete until additional customer meetings are held, however the prospectus refinements must be completed within 30 days. Once the project is established in the project management system, the team should begin charging project related time against the project. Please visit WIRA's web site at https://portal.ds.irsnet.gov/sites/Wira/default.aspx for more information on the prospectus. The prospectus template can be found at https://portal.ds.irsnet.gov/sites/Wira/Approach/Templates%20and%20Checklists/prospectus.Doc.

1.55.7.3.2  (08-30-2012)
Step 2: Project Planning

  1. The project planning stage of the project lifecycle involves assembling a project team, conducting a formal project kick-off meeting, and documenting the project planning process. Parts of this step may not be applicable for Ad Hoc and Infrastructure projects.

1.55.7.3.2.1  (08-30-2012)
Assemble Project Team

  1. The WIRA senior manager assembles a project team upon formal approval from the WIRA Director and the operational executive, and upon assessment of research group workload capacity. After assessing project needs, the WIRA senior manager selects researchers who possess the requisite skills and experience. Selection may also be based on researcher availability or developmental opportunity.

  2. Project team members are responsible for different tasks throughout the project lifecycle. All team members must be aware of how each task is related to the project as a whole and the overall success of the project. While specific project team members are responsible for specific tasks within the planning stage of the project and through to the completion of the project, the entire team is responsible for timely meeting all milestones.

  3. The project team consists of the following roles:

    Role Description
    Project Lead Every project is assigned a project lead. The project lead is responsible for completing the project prospectus and research plan (if Program or Standard project), initiating customer meetings, ensuring that all relevant tasks and milestones are identified, ensuring all task target dates and milestones are timely met, appropriate deliverables are developed, and updating the project status on the project management system
    Technical Lead Projects are assigned a technical lead if the project lead does not have sufficient technical expertise based on the needs of the project. The role of the technical lead is to conduct the initial review of the prospectus, research plan, and deliverables and to serve as a consultant on the project. The technical lead may also conduct data quality review. In some cases, the WIRA senior manager serves in this role. Some situations may call for a technical lead to be assigned to the project from another WIRA research group.
    Other Team Members The number of team members on a project depends on the scope and size of that project. Other team members generally refers to members on a project who do not function in any of the above mentioned roles. In some cases, roles may overlap.

    Note:

    Every Standard project has analyst(s) who conduct independent analysis to replicate or examine data/analysis output to ensure its accuracy. Ad Hoc projects requiring data analysis will also undergo this type of data quality review.

1.55.7.3.2.2  (08-30-2012)
Conduct Formal Project Kick-off Meeting

  1. The formal project kick-off meeting presents an opportunity to reinforce customer expectations and project details established during initial customer discussions and documented in the prospectus. The purpose of this formal meeting is not to gather additional decisional information, but rather to confirm agreement regarding project objectives, key deliverables, deliverable due dates, key milestones, and resource requirements. Milestones established at this meeting, or during prior discussions, will drive the scheduling of status meetings, delivery of interim results with the functional customers, and the formal briefing of operational executives.

  2. Complete a draft version of the prospectus prior to this formal project meeting. If any gaps exist in the prospectus, the meeting may be used to get clarification. If, after sharing the prospectus with the functional customer, significant changes are made, it must be returned to the WIRA senior manager for reconsideration. The formal project kick-off meeting also presents an opportunity to introduce the project to team members who were not involved in the initial discussions.

  3. During the formal project kick-off meeting, the project team is responsible for establishing or reinforcing the following information as identified during project assessment (see IRM 1.55.7.3.1 Step 1: Project Assessment):

    • Rationale

    • Operational change

    • Measure of impact

    • Comparative value

    • Time frame for results delivery

  4. In addition, the project team must discuss with the customer the anticipated data needs and sources. Based on this discussion, the project team must determine:

    • Method for obtaining data (e.g., focus group or data from existing data sources).

    • Ability of customer to provide data, if applicable, and length of time it will take to deliver the data.

    • Data usage requirements (e.g., data access and data security).

    • Data limitations (e.g., restrictions on how the data can be used).

    • Data costs, if applicable, and who will pay those costs.

  5. Finally, the project team needs to discuss with the customer how the customer wants research results delivered. This includes determining what products will be delivered and to whom. Project team members should specify the deliverable(s) format (e.g., Excel spreadsheet, full report, executive summary only, PowerPoint presentation, etc.), due date, and delivery method. The project team will provide a written report as well as an oral presentation of findings (if requested) to the customer for all Programs and Standard research projects.

1.55.7.3.2.3  (08-30-2012)
Document Planning Process

  1. Documentation of the planning process is required for all Program and Standard projects. This includes: refining the project prospectus, conducting background research, and preparing the research plan. The research plan is optional, but is recommended to ensure that the plan is sufficiently documented. If the research plan is not developed, the prospectus and any other project planning documentation must contain sufficient detail of the methods and analysis used for the project.

    Refine project prospectus - The prospectus is required for all Program and Standard projects and serves as a contract between WIRA and the customer regarding the work to be completed. Initial discussions with the customer provide the basis for development of the prospectus, including such items as project description, business objectives, research questions, projected resource needs and project deliverables. Following the formal project kick-off meeting the research team refines or completes any incomplete sections. The prospectus template is located at https://portal.ds.irsnet.gov/sites/Wira/Approach/Templates%20and%20Checklists/prospectus.Doc.

    Conduct background research - Conducting background research for a project serves as a mechanism to confirm assumptions discussed during the initial and subsequent discussions with the customer. This step includes both an internal and external review of research literature and should include items relevant to the research question(s), as well as the method(s) to be used for the project. This background research impacts how the current project is informed by, builds on, modifies, or uses methods of prior work. An exhaustive listing is not necessary. Examples of background resources include:

    • The WIRA Project archive - https://portal.ds.irsnet.gov/sites/WIRAProjArchive

    • Research services on ReferenceNet - http://rnet.web.irs.gov/index1.htm

    • IRS Research Project Directory - http://researchcouncil.web.irs.gov/IRS%20Research%20Project%20Directory.htm

    Prepare research plan (optional) - The research plan functions as an internal “roadmap” for completing a research project. The research plan contains a detailed description of the research method, data, and analysis that is used to address the research question(s). It should be written clearly and completely so that another researcher can replicate, solely from reading the plan, the methods and analysis used. The research plan is not required but is recommended for Program and Standard projects. The research plan must be maintained in the project folder. Please refer to the research plan review checklist at https://portal.ds.irsnet.gov/sites/Wira/Approach/Templates%20and%20Checklists/planCriteria.doc. Once the research plan is approved by the senior manager, any significant deviation from the plan or the prospectus must be documented in the project management system. Significant changes affecting the nature of the deliverable, resource requirements, or timing must be approved by the WIRA Director.

1.55.7.3.3  (08-30-2012)
Step 3: Data Gathering

  1. The security of taxpayer data is of paramount importance. IRS has an obligation to protect taxpayers’ privacy and limit the possibility of identity theft and fraud when collecting, storing, and analyzing personal and financial information about taxpayers. All WIRA employees using or creating data, regardless of how and where stored, are personally responsible for making it secure and available only to authorized personnel. Every member of the project team is responsible for this security objective.

  2. Data must be destroyed in an appropriate and timely manner as outlined in IRM 1.55.7.5 Data Retention and Security.

  3. During the data gathering process, it is important to consider the following limitations and procedural needs:

    • Only data relevant to answer the research and possible follow-on questions should be collected.

    • Project data may be readily available within IRS (e.g., Individual Return Transaction File (IRTF), National Research Program (NRP), and Earned Income Tax Credit (EITC)). Be aware that some internal data sources have usage limitations and/or requirements.

    • Projects may require external data such as U.S. Census Bureau or Social Security Administration data. The logistics and costs of acquiring external data will vary by data source and should be researched during the planning stage.

    • If collecting primary data from taxpayers, determine if OMB approval is needed, and then follow appropriate procedures. See http://opera.web.irs.gov/SRCSurveySubgroupWebFiles/DoingASurveyPage.htm#Public for more information on collecting information from the public.

    • If requesting primary data from IRS Bargaining Unit employees, determine if the National Treasury Employee Union (NTEU) needs to be notified, and then follow appropriate procedures. See http://opera.web.irs.gov/SRCSurveySubgroupWebFiles/DoingASurveyPage.htm#Internal for more information on conducting surveys to collect information from IRS employees. See Article 8 Section 8 of the NTEU National Agreement.

1.55.7.3.4  (08-30-2012)
Step 4: Data Analysis

  1. Guidelines for data analysis begin with documentation in the research prospectus and research plan, if available. In addition, data analysis involves providing description of data variables, data validation, and ensuring accuracy of data analysis. The following steps may not be applicable for Ad Hoc and Infrastructure projects but must be followed for all Program and Standard projects. The steps for data documentation and analysis include:

    Documentation of data needs - The data and methodology section of the prospectus or the data needs section of the research plan must completely and accurately document the data used for the project and the data validation method. The documentation includes the various data sources and how each is used. Ensure documentation is sufficient so that another researcher can acquire and validate the data based on this documentation. The project lead shall ensure that this documentation is properly stored in the project folder.

    Description of variables - The project team is responsible for describing and documenting the variables and methods used to analyze the data. The documentation should contain information on the variables used in the analysis, such as new variables developed and variables used for filtering. The syntax for the analysis should be placed in the project folder along with a description of the methods used for data analysis to the extent that it may be later replicated by another researcher.

    Data validation - It is the prerogative of the senior manager and the project team to determine exactly how to validate the data, but validation should include activities that ensure soundness of the data. Data validation may include, but is not limited to, checking:

    • Field formats

    • Data types

    • Range of values

    • Presence of outliers

    • Missing data

    • Distribution shapes

    • Cross validation between data sets

    Data accuracy - Every Program and Standard project must undergo data quality review. A project team member conducts an independent analysis to replicate the output and thus ensure its accuracy. It might include processing data in a manner that is different than that used by the first researcher to see if the same results are achieved. Note that simply completing the same process, perhaps using the same syntax, does not ensure accuracy. See IRM 1.55.7.4.2 Data Quality Review for more information on performing data quality review.

  2. WIRA researchers are expected to share interim findings, if available, with the customer during the course of completing the project to ensure that the agreed upon research question(s) are being addressed. These results may also provide a basis for interim decisions by the customer. These interim sessions must be noted in the project status section of the project management system.

1.55.7.3.5  (08-30-2012)
Step 5: Communication of Results

  1. Research results are communicated to the customer in a format that is clear, understandable, actionable, and representative of a professional product. While the deliverable for Program, Standard, and Ad Hoc projects may vary (e.g., Word documents, PowerPoint presentations, Excel spreadsheets), the final product must clearly address the project’s research questions and respond to the customer's business objectives. All WIRA deliverables must undergo a document quality review. See IRM 1.55.7.4.1 Document Quality Review for more information on completing a quality review.

  2. To prevent misunderstandings with the customer regarding the deliverables, the project team should schedule and maintain regular communication with the customer contact(s). The project team should share interim results with the customer to ensure that the customer has enough information to make project-related changes, if necessary. There should be no differences in product expectations between the project team and the customer.

  3. If desired by the customer, the project team conducts an oral presentation for the sponsoring executive and analysts to summarize the research findings and recommendations. Presentation and briefing materials must be prepared and quality reviewed prior to sharing with the customer. Presentation materials should clearly reflect the interests and preferences of the customer. See IRM 1.55.7.4.1 Document Quality Review for more information on quality reviews.

1.55.7.3.5.1  (08-30-2012)
The Research Report

  1. Write the research report for the benefit of the customer. This means the final report must fully meet the customer expectations and provide guidance for effecting valued operational change. The role of a WIRA analyst and/or project team is not to simply produce and present data or findings. WIRA's value lies in integrating research data analysis, operational data, and other relevant information to provide insights responsive to the customer's operational objectives.

  2. Complete the research report for all Program and Standard projects. Tailor the report to the format and manner established with the customer at the formal kick-off meeting. If report preference was not previously established, or if it changed based on interim findings, the report format should reflect this change. The research questions must be answered and the report delivered to the customer by the agreed upon due date.

  3. Provide a clear discussion of the conclusions and recommendations in the executive summary , if applicable. This section highlights the findings, insights, and recommendations. A well prepared executive summary should serve as a standalone document. The executive summary template can be found at https://portal.ds.irsnet.gov/sites/Wira/Approach/Templates%20and%20Checklists/execSummary.doc. The research report for a Program or Standard project must include an executive summary and follow the prescribed executive summary template.

  4. Follow the quality assurance guidance in the drafting of the research report. See IRM 1.55.7.4.1.2 Quality Review of Research Reports for more information on the quality review.

1.55.7.3.5.2  (08-30-2012)
The Research Report Approval Process

  1. Once the research report is drafted, it undergoes the following steps for approval:

    1. Project lead reviews draft report to ensure that it has been prepared and assembled according to quality assurance process. See IRM 1.55.7.4.1.2 Quality Review of Research Reports for more information on the document quality review process.

    2. Quality reviewer conducts document quality review.

    3. Project team makes necessary revisions resulting from quality review.

    4. WIRA senior manager and technical lead (if applicable) review draft report.

    5. Project team makes necessary revisions resulting from review by WIRA senior manager and technical lead.

    6. WIRA senior manager shares draft report with WIRA Director.

    7. Project team makes necessary revisions resulting from review by WIRA Director.

    8. WIRA senior manager issues the report to customer for review and comment. Customers should be given a minimum of 10 business days to review and make comments.

1.55.7.3.6  (08-30-2012)
Step 6: Post-Research Tasks

  1. Once the research report is completed, approved, and transmitted to the customer, post-research tasks must be completed. While some of these tasks may not be necessary for Program, Ad Hoc, and Infrastructure projects, they are required for all Standard projects. The tasks include conducting a project team close-out meeting, maintaining report and project documents in the project folder, closing the project in the project management system, and conducting a post-research interview with the executive customer to help identify future research support and improvement opportunities.

1.55.7.3.6.1  (08-30-2012)
Conduct Project Team Close-out Meeting with Customer

  1. Though the close-out meeting is often an important part of our process, the customer may not be interested in participating in this meeting. Regardless, the project team should document any lessons learned in the project folder. The following describes this task:

    • Discuss and document project lessons learned and other relevant performance issues.

    • Make improvement recommendations for future research related to the current project.

    • Document discussion and recommendations in the project folder.

1.55.7.3.6.2  (08-30-2012)
Document and Store Project Deliverable and Work Products

  1. Documenting and storing the project deliverables and work products involves the following:

    • Convert final report(s) to a searchable PDF document. Enter the report title, key words, and project number into the file properties of the document. Place the project title and key words in the Title and Key Word sections of the file properties. Record the project number in the Subject section of the file properties.

    • Compile work papers (including data documentation), output, syntax, and data files, as applicable, in the project folder for future use (e.g., audit, similar projects, etc.). This information is archived for future literature searches and for access by those who have a business need. This step applies to Program, Standard, and Ad Hoc projects.

    • Post report(s), work papers, presentation materials, quality review work papers, forms, and certificates in the project folder. The report(s) must go in the Final subfolder of the project folder.

1.55.7.3.6.3  (08-30-2012)
Close Project in Project Management System

  1. The project lead closes the project in the project management system immediately following delivery of the final product to the customer. While a project associated with a Program may close, the Program itself must remain open until the goals of the initiative are achieved or until cancelled by WIRA Director.

1.55.7.3.6.4  (08-30-2012)
Interview Executive Customer

  1. The WIRA Director or senior manager conducts post-research interviews with the sponsoring executive customers after the project has been closed out. This interview is used in part to gather impact and outcome data. This information is documented and added to the project folder.

1.55.7.3.6.5  (08-30-2012)
Conduct Customer Satisfaction Survey

  1. In order to ensure that WIRA is meeting and exceeding its customer expectations, a web-based WIRA Customer Satisfaction Survey is administered annually to executive customers and customer analyst(s). Survey results will be analyzed and formulated into process, document, and other improvements in how we serve our customers.

1.55.7.4  (08-30-2012)
Quality Assurance

  1. Quality assurance is a planned, systematic, and consistent process that provides confidence in a product's accuracy and suitability for its intended purpose. Quality assurance is a critical component for delivering valued and actionable research. It is the responsibility of every member of WIRA to support, promote, and ensure the quality of all WIRA generated research products. Quality research products reflect:

    • Accuracy - degree of data validation and quality review are based on customer and project risk tolerance.

    • Clarity - findings, conclusions, and recommendations are up-front; product is user/customer friendly, and it is organized and uncomplicated to prevent customers from having to put forth unnecessary effort and time to understand text, tables, and/or graphs.

    • Relevance - all research questions are clearly addressed; the “so what” factor is not only met but is also operationally meaningful.

  2. The basic fundamentals of quality research involve:

    • Findings based on the research method

    • Conclusions that address the project’s stated objective(s) and market segment(s).

    • Recommendations that are operationally actionable and address the research questions

  3. Quality research products are the direct result of a commitment from management and research analysts to perform quality review on project deliverables. The nature and extent of the quality review process is dependent on an initial assessment of project content, methods, complexity, and customer tolerance for uncertainty. This assessment looks at the risk factors involved in the project. The WIRA senior manager conducts such an assessment.

  4. The following are some external factors that WIRA management must consider when determining the tolerance level of risk for a project:

    • Stakeholders/customers

    • Business impact

    • Political visibility or relevance

    • Impact of mistakes or uncertainty

  5. Additionally, WIRA management must consider the following internal factors when assessing the risk of a project:

    • Experience of researcher(s) working on the project

    • Data availability/reliability

    • Experience with technique/method

    • Complexity of research or analytic method

    • Specificity of research question(s) and hypotheses

    • Experience with similar projects

  6. Researchers must archive quality review documentation in the project folder.

1.55.7.4.1  (08-30-2012)
Document Quality Review

  1. In-group quality review is conducted by researchers within the WIRA group assigned to the project. Assuming the technical lead has the necessary technical knowledge and is not part of the project team, he/she is responsible for this review. If the technical lead does not have the technical knowledge or is part of the project team, the WIRA senior manager assigns the review to another researcher on his/her staff.

  2. While there is no formal process for conducting an in-group review, researchers assigned to complete these reviews should refer to the WIRA research plan and WIRA research report review criteria as indicated in IRM 1.55.7.4.1.1 Quality Review of Research Plans and IRM 1.55.7.4.1.2 Quality Review of Research Reports to complete their review.

  3. The WIRA senior manager may also solicit support from another research group to assist in the review.

1.55.7.4.1.1  (08-30-2012)
Quality Review of Research Plans

  1. A high-quality research plan is critical to a successful research project. In addition to describing the project’s objective(s), market segment(s), and data needs, the research plan also provides a technical description of the methods and outlines a detailed project action plan.

  2. The elements of a WIRA research plan are briefly described below. For additional details, please see the research plan review criteria at https://portal.ds.irsnet.gov/sites/Wira/Approach/Templates%20and%20Checklists/planCriteria.doc.

    Element Description
    Introduction The introduction sets the foundation for the research project by describing the background, research questions, and objectives. This section provides the reader with a general understanding of the operational or performance problem(s) encountered by the customer and the relationship to W&I objectives. The introduction also includes a brief description of how the report achieves the identified objectives, which may involve a reference to methods used, and data limitations when appropriate.
    Background Research The background research section provides a short summary of information on similar or related studies and their outcomes. It also discusses relevant operational performance data and trends (e.g., Business Performance Review, W&I Operations Plan) and how this information supports the hypothesis being tested or analyzed in the project. Additionally, this section includes a brief description of the methods employed in these studies. All literature referenced must be properly identified and cited.
    Objectives Objectives are what the researcher wants to find out, wants to have, or wants to be able to do when the research is over. This section includes itemized project objectives and describes how each objective is related to the research questions. The objectives should match those in the approved project prospectus.
    Taxpayer/Market Segment The taxpayer/market segment section describes the taxpayer and/or third party market segment(s) that the project addresses. This segment is a clearly defined group that you hope to address and affect with the results of the research.
    Data Needs The data needs section provides a description of the data, variables, data sources, procedures used to obtain data, and Service-wide data standards. Quality research is dependent on an identification and understanding of data needs, data sources, and data limitations.
    Methods The methods section describes how researchers will achieve the project objectives, including an explicit description of the hypothesis, or what is being tested. The methods are described in sufficient detail so that the results can be duplicated by anyone having access to the same data. This section includes a description of the methods, hypotheses, sample design, measurement of results, and action standards.
    Data Analysis Plan The data analysis plan provides a description of the statistical comparisons or tests to be used during data analysis and the rationale for using such statistical comparisons or tests.
    Project Action Plan The project action plan presents a detailed timetable of activities, project phases, and milestones that must be completed to accomplish the project objectives in a timely manner.
    Data Privacy and Security Data privacy and security describes the actions that will be taken to ensure the data acquired for use in a project, and the project results, are handled in accordance with all internal procedures and requirements.
    Signature Page The signature page includes the names of the project team members as well as a name, signature, and date line for the project lead, all analysts involved in the quality review of the research plan, and the WIRA senior manager who approves the final plan.

  3. A research plan template is located at https://portal.ds.irsnet.gov/sites/Wira/Approach/Templates%20and%20Checklists/planTemplate.doc.

1.55.7.4.1.2  (08-30-2012)
Quality Review of Research Reports

  1. The quality review elements of WIRA research reports for Standard projects follow the elements briefly described below. For additional information on these quality review standards, refer to the research report criteria at https://portal.ds.irsnet.gov/sites/Wira/Approach/Templates%20and%20Checklists/reportCriteria.doc.

    Element Description
    Front Matter Every report must have a front matter section that includes the cover/title page, a table of contents, a list of illustrations, and an executive summary (see https://portal.ds.irsnet.gov/sites/Wira/Approach/Templates%20and%20Checklists/execSummary.doc for executive summary template). This section is provided to assist the reader in navigating through the report and provides the reader a brief non-technical summary of the report.
    Introduction The introduction sets the foundation for reading and understanding the research report. This section provides the reader with a general understanding of the problem encountered by the customer and its importance, a brief summary of the background and objectives, and the purpose and structure of the report. The section should clearly define both the research objectives and the hypotheses being tested.
    Findings Findings are the answers to the research questions and hypotheses resulting from data analysis. Significant findings should be clearly presented in an objective manner that does not make unsupported judgments about the results.
    Conclusions The conclusions section should provide the reader with an analysis and interpretation of the findings. Conclusions should flow logically from the findings and be clear and easy to read.
    Recommendations The recommendations section describes the operational changes that could or should be taken based on the findings and conclusions. The section should provide sufficient explanation to support the recommendations. Recommendations should reflect the discussions with the customer such that they reflect the attributes of relevance, priority, and feasibility. If there are disagreements regarding the recommendations or no recommendations have been made, the report provides support for this decision.
    Signature Page The signature page includes the names of the project team members as well as a name, signature, and date line for the project lead, all analysts involved in the quality review of the research report, the WIRA senior manager, and the WIRA Director. The signature page can be found at https://portal.ds.irsnet.gov/sites/Wira/Approach/Templates%20and%20Checklists/signaturePage.doc.
    Appendices Appendices contain information that is too lengthy or technical to be presented in the body of the report or is of interest to only a few readers. An example is a research methods appendix that provides a detailed description of the methods or sampling plan. Other information contained in the appendices section may include an Official Use Only certification form, copies of survey instruments or other data collection instruments, testing materials, moderator guides, detailed tables and charts, findings not appropriate for the body of the report, and/or references.

1.55.7.4.1.3  (08-30-2012)
Quality Review of Other Research Products

  1. All research deliverables undergo a quality review. The quality review elements of other deliverables, such as PowerPoint briefings and Ad Hoc projects, must be tailored to the specific project or research request. Similarly, the quality review elements used in Infrastructure projects will vary depending on the deliverables and function responsible. WIRA recommends that the quality review elements of research reports be used as a reference/foundation for these other deliverable and projects; however, certain research report quality review elements may not always be applicable (e.g., Ad Hoc projects often do not include operational recommendations as typically found in Program and Standard projects).

1.55.7.4.1.4  (08-30-2012)
WIRA Style Guide

  1. As a part of our commitment to quality, all research reports, plans, and PowerPoint presentations must follow the WIRA Style Guide. The Style Guide ensures that our documents have a professional and consistent appearance. The Style Guide contains rules for font types, margins, page headers, table of contents, tables, charts, citations, templates, proper term usage, etc. Please access the WIRA Style Guide at https://portal.ds.irsnet.gov/sites/Wira/Approach/Templates%20and%20Checklists/WIRA%20Style%20Guide.doc.

  2. If additional guidance is needed, please refer to the IRS Communicators' Style Guide at http://irweb.irs.gov/AboutIRS/bu/cl/comm/style/default.aspx or speak to your manager.

1.55.7.4.2  (08-30-2012)
Data Quality Review

  1. All WIRA research projects will be subject to a data quality review process. This quality review requirement ensures that each project’s data validation and analysis are thoroughly reviewed for technical accuracy before being released to the customer. The data quality review differs from the document quality review in that the data quality review focuses solely on accuracy and validity of project data and analysis.

  2. Data quality review practices are embedded into every step/process of a research project involving data such as data gathering, data manipulation, data analysis, and data presentation. An analyst (ideally on the project or in the same research group) independently validates the accuracy of method, syntax, data analysis, and results of the research project. Independent validation is crucial, as a mere re-run of the original syntax does not constitute data quality review. The WIRA senior manager determines up-front during the initial project risk assessment the extent and/or level of validation required for the project.

  3. The steps for performing data quality review are as follows:

    1. The WIRA senior manager designates a project team member or group member as the data quality analyst for the research project or for specific activities within the project. This implies that more than one analyst can perform data quality review for a project.

    2. When developing the project plan, the WIRA senior manager or project lead outlines the specific tasks/duties of the data quality analyst.

    3. The data quality analyst independently validates those tasks as outlined during the planning of the project. He or she is also responsible for the independent quality review of any additional tasks that arise while the project is being worked/completed.

    4. If discrepancies are discovered, the primary researcher(s) responsible, the data quality analyst, and the project lead discuss the discrepancies to uncover the source of error and devise a solution.

    5. The data quality analyst documents the data quality review. A data quality review template can be found at https://portal.ds.irsnet.gov/sites/Wira/Approach/Templates%20and%20Checklists/embeddedReview.doc. The data quality analyst completes the data quality review document and posts it in the project folder.

1.55.7.4.3  (08-30-2012)
Quality Assurance Roles and Responsibilities within WIRA

  1. Quality assurance is the responsibility of every member of the project team. However, to execute the quality review process, specific roles and responsibilities are detailed to ensure that each review is completed expeditiously.

    Role Description
    WIRA Director At his/her discretion, the WIRA Director reviews a sample of project documents to serve as a quality check and to facilitate cross-functional knowledge sharing. The Director reviews all final research reports and the Director’s designee(s) reviews appropriate quality assurance documentation to verify certified completion. Before a product is submitted to the Director’s staff for review, it has undergone data quality review, document quality review, and review by a WIRA senior manager.
    WIRA Senior Manager WIRA senior managers are ultimately responsible for ensuring that their group’s work adheres to WIRA’s quality assurance standards. As part of this responsibility, WIRA senior managers assess the document quality review needs of a project’s deliverable and identify the in-group reviewer. The senior manager also ensures that project data analysis undergo a data quality review. The WIRA senior manager documents their approval and acceptance of all project deliverable.
    In-Group Reviewer Research analysts may be called on to serve as in-group reviewers. In that role, they evaluate a project deliverable for accuracy, clarity, and relevance to the customer. They should refer to the research report review criteria (https://portal.ds.irsnet.gov/sites/Wira/Approach/Templates%20and%20Checklists/reportCriteria.doc) as a guide for their review. Following his/her review and final approval of the deliverable, the in-group reviewer documents the review and posts it in the project folder.
    Data Quality Reviewer Research analysts may be called on to serve as data quality reviewers. All WIRA research projects that require data analysis must undergo data quality review. The data quality reviewer independently validates the accuracy of method, syntax, data analysis, and results during the process of the project. The data quality reviewer documents the review and posts it in the project folder.

1.55.7.5  (08-30-2012)
Data Retention and Security

  1. WIRA manages access to Compliance Data Warehouse (CDW) data by using the 5081 process to authorize usage rights. The following outlines this process:

    1. Users make requests for masked and unmasked Taxpayer Identification Numbers (TINs) through the 5081 process. Requests for unmasked TINs require approval from the WIRA Director or the designated proxy, and a detailed e-mail from the requestor's director approving the request. This e-mail includes an explanation for the use and length of time data is needed (the default is 120 days). The request is retained as a part of the documentation package.

    2. When a new unmasked TIN request is received via OL5081, the designated WIRA approver places the request on hold and contacts the applicant's manager via e-mail and telephone to outline the procedure. Once an e-mail is received from the requesting director, the request is processed.

    3. The WIRA Director or designee conducts a formal review of the total inventory of data access requests every 6 months.

  2. WIRA manages retention of data on WIRA servers. Data stored on WIRA servers include data from the CDW, surveys, interview transcripts, etc.

    1. Data expires no more than two years from the date of receipt unless an explicit retention exception is granted. Expired data is purged to meet W&I, Service-wide Research Council and IRS cybersecurity requirements.

    2. Prior to the two year expiration, the senior manager and project lead will receive notification indicating that project data will be expired. The notification will describe the options available which include manual deletion of the data files or request for exception.

    3. A retention exception requires an authorized project plan which specifies future use of the data. This data is then moved to the ongoing studies area.

  3. Each research project has a project lead who oversees security for project information.

    1. Secure folders are created giving the project lead management rights.

    2. The project lead assigns other team members rights as necessary. For more information on how to modify folder rights, please see the Adding Users to Project Folders Job Aid (https://portal.ds.irsnet.gov/sites/Wira/Shared%20Documents/Job%20Aid%20-%20Adding%20users%20to%20project%20folders.zip).

    3. In the case of CDW data and the prospectus or research plan indicates the need for Personal Identifiable Information (PII) data, the project lead must ensure that access to such data is restricted to team members of the 5081 group for unmasked TINs.

  4. Data for multi-year ongoing studies is maintained in a secure environment specifically for long term data. Unmasked TIN data is handled through the regular unmasked process as described above. A project may be identified as an ongoing study at project start or may evolve into an ongoing study as the project progresses. Once it is determined that the project is an ongoing study, the analyst must contact WIRA's Knowledge Infrastructure group for access to the ongoing studies area.

  5. The approved process for receiving files from entities outside WIRA is the Enterprise File Transfer Utility (EFTU). This system authorizes and transfers electronic files to and from external organizations within and outside of the IRS.

1.55.7.6  (08-30-2012)
Survey Contract Administration

  1. The Survey Administration and Analysis (SAA) team coordinates and monitors the contract life cycle process for W&I and External Customer Satisfaction Surveys (CSS). The SAA team members are certified Contracting Officer Representatives (COR) who serve as the liaison between the Contractor and Procurement. The SAA COR is responsible for preparing and submitting the administrative documents associated with the survey contract process.

  2. The SAA COR and the Procurement Contracting Officer (CO) work as a team to ensure program requirements are clearly defined and the contract is written to meet them. Together, they are responsible for ensuring that competitive sources are solicited, evaluated and selected at a price which is fair and reasonable to the Government.

  3. The SAA COR is responsible for ensuring compliance with quality standards, performance measures and delivery requirements. The SAA COR is the principal program representative assigned to Government procurements. The COR is responsible for monitoring the contractor’s performance against the contract requirements and must report any deviation to the CO.

  4. The SAA COR must stay in close communication with the Contractor and the CO, relaying any information that may affect the contractual commitments and requirements.

  5. SAA CORs may be given certain limited authority to act on behalf of the Contracting Officer, particularly in providing technical direction to the contractor. SAA CORs cannot obligate the Government or change the terms or conditions of contracts - only a CO has this authority.

  6. For more information on COR training opportunities, certification information, and other general responsibilities, visit http://awss.web.irs.gov/Procurement/tai/cotrs.shtml.

1.55.7.6.1  (08-30-2012)
Survey Contract Life Cycle

  1. A contract is a mutually binding legal relationship obligating the seller (the contractor) to furnish the goods/products or services requested and the buyer (the Government) to pay for them. The SAA COR is responsible for monitoring the terms and conditions by all parties as outlined in the contract.

  2. The survey contract life cycle process consists of 4 stages:

    1. Survey contract acquisition

    2. Survey contract administration

    3. Survey contract modification

    4. Survey contract close-out

  3. All contracts must have certain terms and conditions to be enforceable. Because courts rely on the meaning of the language of a contract to enforce it, this language must be clear and concise. It is the responsibility of the SAA COR to ensure that the Performance Work Statement (PWS), Statement of Objectives (SOO), or Statement of Work (SOW) communicate clear requirements.

1.55.7.6.1.1  (08-30-2012)
Survey Contract Acquisition

  1. It is the responsibility of the SAA COR to know that the acquisition process involves several methods of solicitation which determines the processing of requirements through to award.

  2. Customers who do not have a survey in place and have identified a need for one should contact the WIRA SAA senior manager and the WIRA senior manager for the associated research project. The WIRA senior managers work with the customer to identify needs, funding source, and to determine if the survey should be administered in-house or through a contractor. All survey requests must be submitted to the WIRA Director for approval.

  3. Customers, who already have a survey in place and wish to continue survey services, are required to submit a narrative justification each year. Funding authorization and approval must be documented by W&I Finance. The SAA COR is responsible for assisting with the preparation of the narrative justification.

  4. The SAA COR works with the WIRA research analyst as well as the customer contact to obtain survey services. The steps below outline the procedures for obtaining these services:

    1. The SAA COR, together with the function representative(s) and the WIRA research analyst, prepares the Performance Work Statement (PWS) for the base year and subsequent optional years, if applicable.

    2. The SAA COR prepares the Independent Government Cost Estimate (IGCE) to determine budget amounts.

    3. The SAA COR prepares the Quality Assurance Surveillance Plan (QASP) to outline how IRS measures the quality of the work, timeliness of delivery, and the budgetary guidelines.

    4. The SAA COR prepares the Performance Requirements Summary (PRS) to document the desired outcomes, performance objectives, performance standards, and acceptable quality levels.

    5. The SAA COR prepares the 508 Compliance Determination (Form 14038) to identify and record compliance of contracted product.

    6. The SAA COR prepares and submit the funded requisition (Form 1334) via the Requisition Tracking System (webRTS). The SAA COR must attach the PWS, IGCE, QASP, PRS, and Form 14038 to this submission. Once the requisition is received, the CO prepares the Request for Proposal (RFP) and submits the package for bidding.

    7. The SAA COR works with the function contacts to establish a Technical Evaluation Panel (TEP). This panel must objectively evaluate the technical and cost proposals received from the prospective offerors who have met the requirements of the RFP.

    8. The SAA COR prepares and submits OMB supporting documentation to OMB. As a result of the Paperwork Reduction Act, OMB must provide clearance for all surveys that are distributed to taxpayers. The clearance is to ensure that the paperwork burden for taxpayers is minimized.

1.55.7.6.1.2  (08-30-2012)
Survey Contract Administration

  1. Contract administration is the process of ensuring that the contract is performed as agreed upon by the Contractor and the Government. Administration of a contract begins after negotiations are successfully concluded and the contract is signed. The CO is responsible for Contract Administration as outlined in the Federal Acquisition Regulation (FAR) Subpart 42.3 for Contraction Administration Functions at https://www.acquisition.gov/far/current/html/Subpart%2042_3.html#wp1078235. However, the CO may delegate certain contract administration duties to the COR. As a part of these duties, the COR must:

    • Monitor the contractor’s technical progress against contract milestones and deliverables

    • Approve invoices for payment in accordance with contract terms

    • Control Government property by ensuring data is destroyed or returned according to the Performance Work Statement

    • Review purchase, delivery, and task orders

    • Report to Procurement any contractor equipment downtime

    • Review contract change proposals and recommend appropriate action to the Contracting Officer

    • Facilitate contract modifications (See IRM 1.55.7.6.1.3 Survey Contract Modification)

    • Perform all other administrative tasks required by the contract

  2. The COR should use the following checklist to ensure that contract files are complete with all required documentation:http://awss.web.irs.gov/Procurement/forms/cotr_contract_administration_checklist%20.doc.

1.55.7.6.1.3  (08-30-2012)
Survey Contract Modification

  1. During the contract lifecycle, modifications may be necessary to incorporate new requirements or to include new developments after the contract has been awarded. These changes can be identified by the contractor, the functional contact, program manager or the SAA COR. Regardless of who identifies the change, the SAA COR must do the following:

    • Communicate and describe the proposed change(s) to the Procurement CO.

    • Initiate and prepare the Web-RTS submission to describe the requested change.

    • Monitor contract performance against the modified contract language.

  2. All contract modifications must be issued in writing by a CO. SAA CORs cannot modify contract requirements.

1.55.7.6.1.4  (08-30-2012)
Survey Contract Closeout

  1. Contract closeout is the responsibility of the COR and CO. The SAA COR is required to certify that receipt of all goods and services were rendered in a satisfactory manner and all deliverables are complete and acceptable.

  2. Contract closeout is necessary in order to verify that Government funds were properly expended and to ensure that excess funds are de-obligated.

  3. Upon completion of the contract, the SAA COR must ensure the following:

    • Review and approve final invoice

    • Enter Receipt and Acceptance (R/A) into webRTS

    • Ensure all deliverables were received

    • Respond to Procurement for contract closeout documentation

    • Ensure that the contract administration file is properly documented

    • Ensure that Government property, if used, is properly returned

    • Obtain contractor releases from further claims

    • Provide contractor’s performance information to CO for submission into the Contractor Performance System (CPS)

  4. The SAA COR should use the following checklist to certify that all close out documentation is complete: http://awss.web.irs.gov/Procurement/forms/admin_close.doc.

1.55.7.6.2  (08-30-2012)
Service-wide Contracting Officer Representative (COR)

  1. The role of the SAA Service-wide COR sets the overall tone of the W&I Customer Satisfaction Program. The SAA Service-wide COR is responsible for establishing and building close relationships with both WIRA research analysts and the Business Unit contacts. The Service-wide COR has the following responsibilities:

    • Serves as a liaison between all Business Operating Divisions (BOD), WIRA analysts, and Procurement for the Customer Satisfaction Surveys (CSS) Blanket Purchase Agreement (BPA).

    • Serves as a liaison between the BOD(s), WIRA analysts, and Media and Publications concerning the General Print Office Print Contract for the CSS.

    • Serves as a liaison between Cybersecurity and contractors/sub-contractors for site security visits. The SAA Service-wide COR sends contractor site information to Cybersecurity and coordinates these site security visits. For more information see memo from Procurement on managing contractor employee access to IRS owned facilities at http://awss.web.irs.gov/Procurement/policy/pandp/pp39-1c.pdf.

    • Works with Contractor Security Lifecycle Program (CSLP) to facilitate background investigations for contractor/sub-contractor personnel.

    • Serves as a point of contact for TIGTA/GAO audits and correspondence.

    • Coordinates with Information Resources Accessibility Program (IRAP) for 508 compliance for Task Order under the CSS BPA. The SAA Service-wide COR ensures that the Task Order indicates 508 compliance requirements. The SAA Service-wide COR also works with the contractor and IRAP to help contractor become 508 compliant.

    • Assists with publication of BPA/CSS listing on IRS.gov web site. The SAA Service-wide COR ensures that the listing is accurate.

    • Serves as Issue Management Resolution System (IMRS) Coordinator for BPA.

    • Serves as Office of Privacy, Governmental Liaison and Disclosure (PGLD) Coordinator for BPA. The SAA Service-wide COR coordinates with PGLD, the BOD(s), WIRA analysts, and the contractor to resolve any issues related to privacy, disclosure, and security. Additionally, the SAA Service-wide COR coordinates with SAA CORs to ensure that Privacy Impact Assessment (PIA) is updated.

    • Serves as General Legal Services (GLS) Coordinator for BPA. The SAA Service-wide COR coordinates with GLS to determine legal issues and disseminate to concerned parties.

1.55.7.7  (08-30-2012)
Administrative Responsibilities

  1. To ensure effective management of our resources and time, WIRA employees are required to complete certain administrative tasks.

1.55.7.7.1  (08-30-2012)
Project Management System Usage

  1. While this manual is not a user guide for the project management system, you must provide certain key information to enable effective project management in WIRA. At the start of the project, the WIRA employee tasked with entering information in the project management system must provide abstract data in the project management system. Abstract information includes:

    1. Title of proposed project

    2. WIRA group assignment

    3. Customer

    4. Project lead

    5. Brief description of the project and project deliverables

    6. Business objectives of the project

    7. Research questions to be addressed

    8. Expected outcomes

    9. Data sources

    10. Resource requirements

    11. Delivery expectations and dates

  2. In addition to the project abstract, the designated WIRA employee must complete a project prospectus for Program and Standard projects. The project prospectus documents the research activities, staffing and delivery commitments, and funding requirements agreed upon by WIRA and the customer. Information to be included in the prospectus are:

    1. Project number and title

    2. Project initiation date

    3. Estimated completion date

    4. Rationale (performance impact and/or benefits)

    5. Research questions and hypotheses

    6. Data and methods

    7. Project milestones

    8. Estimated project resources (staff, staff hours, travel, training, etc.)

    9. Approvals

  3. WIRA researchers must also enter project status information according to the format and frequency required by their senior manager. The project status information may include progress made so far, changes in customer expectations, challenges, accomplishments, etc.

  4. Finally, WIRA researchers must record the amount of time spent on specific projects, general activities, as well as time spent away from the office. For more information on how to record time, see IRM 1.55.7.7.2 Timekeeping Guidelines.

1.55.7.7.2  (08-30-2012)
Timekeeping Guidelines

  1. Recording and tracking time spent on work related activities are an important part of ensuring that WIRA meets its performance goals. By accurately recording the hours spent on projects, other activities, and absences, WIRA’s senior managers and Director can better assess workload capacity, resource efficiencies, and project allocation needs.

  2. WIRA’s timekeeping categories are broken down into 3 different categories: project hours, non-project hours, and leave hours.

1.55.7.7.2.1  (08-30-2012)
Project Hours

  1. All work relating to an actual open project should be recorded in the project management system on a daily basis, if possible. In the case where the researcher is not able to access the system, he/she must record the hours using an alternative method and then transfer that information to the project management system as soon as possible.

  2. Project time is any activity directly related to an open project. This means that if it was not for the existence of the project, that specific activity would not be performed. Project related time includes (not all-inclusive): meeting with the customer, obtaining and analyzing data, writing reports, conducting background research, planning the project, and conducting the closeout session. If travel is required for the project, the time en-route would also be considered project time.

1.55.7.7.2.2  (08-30-2012)
Non-Project Hours

  1. Non-project hours are hours spent at work, but not directly related to a specific project. The table below shows the different categories of non-project hours that WIRA currently recognizes:

    Non-Project Hours Description
    Continuing Professional Education (CPE) CPE is used to capture time relating to planning and/or attending a Strategy and Finance CPE.
    Project Planning Project Planning is used to capture time related to assessing a project idea before it becomes a project in the project management system. This project idea may actually never become a project, but any work associated with evaluating the idea would be charged against this account. This code is also used for any activities connected with becoming more familiar with the customer's operations.
    Self-Development Self Development is used to capture time related to increasing general knowledge, but would not necessarily be considered formal training. This includes seminars, workshops, general information gathering to increase knowledge in a particular area, and shadow assignments. This would also include Enterprise Learning Management System (ELMS) training that cover topics like the Career Learning Plan (CLP), Performance Plan, and general self/professional improvement topics.
    Internal Consulting Internal Consulting is used to capture time related to helping or training others within WIRA with regards to using a specific tool or application, understanding research related or organization specific methods and techniques, writing code to pull or analyze data, and general questions. This also includes work related to requests from the Director's staff that's not specifically tied to a project. However if the assistance is tied directly to a project, the time should be charged against that project number, even if that project is owned by another research group.
    External Consulting External Consulting is used to capture time related to answering questions or requests from people outside of WIRA. This also includes customer initiated questions not relating to a project or project idea, or minor participation in an external focus group. Additionally, it can include time relating to work for a project that has already been closed. However, if the scope of the activities expands to more than a few hours, a new Ad Hoc project should be created to keep track of this time.
    Training and Conference Training and Conference includes time spent in formal training sessions and conferences. This would include instructor-led onsite or offsite courses, online courses, and ELMS courses relating to improving technical expertise.
    Details Out Details Out is used to capture time when detailed to a group outside of WIRA.
    Administrative and Collateral Duties Administrative and Collateral Duties is used to capture time related to tasks, such as: updating project and time information in the project management system, operational reviews, staff meetings, town hall meetings, project reviews, completing Form 3081 Employee Time Report, computer problems and installs, completing employee engagement surveys, writing self assessments, checking e-mails, participating in the peer group, contributing to the WIRA discussion boards, and other general administrative duties.
    On-the-Job Instructor (OJI) OJI is used to record time spent performing On-the-Job Instructor duties.

1.55.7.7.2.3  (08-30-2012)
Leave Hours

  1. In order to accurately assess workload capacity, WIRA needs to account for time away from the office. The most common categories of leave time that WIRA uses are: Annual Leave, Sick Leave, Holiday, Admin Time, and Credit Taken. However, there are other types of leave recognized in the Service. For a detailed description of each leave category, please refer to IRM 6.630.1, IRS Absence and Leave and IRM 6.550.1, Pay Administration.


More Internal Revenue Manual