GADS3_Attachment_J_2_TaskOrder_1_Final.docx

ATTACHMENT J-2 “AASC” WORK STATEMENT TASK ORDER 1

ATTACHMENT J-2 WORK STATEMENT – Task Order 1 Automating Application Status Changes (“AASC”) in IMPAC II

NATIONAL INSTITUTES OF ENVIRONMENTAL HEALTH SCIENCES

RESEARCH TRIANGLE PARK, NC

Table of Contents

1.0 INTRODUCTION:

This task order work statement is to obtain Application Development, Modernization, and Enhancement (DME) services for the DERT Grants Funding Decision Tool (GFDT). The Government intends to award this labor hour task order with the IDIQ base contract award. The objective of this Task is to automate the change of application status in IMPAC II (“AASC” Task Order).

2.0 SCOPE:

The GFDT is a .Net application internal to NIEHS designed to help manage the external grants funding decision-making process, track the funding plan, and provide transparency into the funding decision-making process. It reads data from the IDC via an Oracle database materialized view and performs functions using a SQL Server back-end and IIS 7 Application Server. ASP.Net MVC (C#) is the framework used for the application’s base code. HTML, knockout.js, Javascript, and CSS are used to build the user interface. IDC imports data nightly from IMPAC II. Currently GFDT is not writing any information back to IMPAC II.

DERT utilizes the GFDT to track NIEHS extramural funding decisions and to create, track, and approve funding plans. Once funding plans are approved, the Council Coordinator currently needs to manually enter the IMPAC II Intent to Pay Module to change the status of each application that NIEHS intends to fund. DERT funds approximately 1,500 applications per year. Automating this manual task will save significant staff time and reduce the possibilities for human error.

3.0. TASKS:

The Contractor shall provide the following services under this task order.

3.1 Task Order Management

The GTM is responsible for technical monitoring of Contractor task performance on behalf of the task order Contracting Officer Representative. The GTM will ensure the Government effectively measures service levels and continuously conducts quality assurance to assess the Contractor’s performance at all times. The Contractor’s performance shall be monitored using the attached GADS3 Quality Assurance Surveillance Plan (QASP)(Base Contract Attachment J-9).

3.1.1 Task Order Project Plan

Within 10 calendar days after task order award, the Contractor shall provide a Project Plan (see DEL DME.C.7.2-1 in base contract) that addresses the following lifecycle phases of the AASC project:

· Need/Concept

· Definition

· Design

· Execution of Solution

· Deployment

· Operate and Maintain The Contractor shall use the plan to identify the project approach as either “Conventional” with project milestones or “Agile” with sprint outcomes and structure the plan accordingly. The Contractor shall meet or exceed DME Project Performance Objectives identified in Table 5 (“Lifecycle Maintenance Response and Resolution Levels) and Table 7 (Lifecycle Maintenance Application Availability Service Levels”) in the GADS3 base contract. The project plan shall identify whether and how prototypes and/or pilots will be used as part of the AASC effort.

3.1.2 Task Order Quarterly Review

The task order quarterly review shall take place as part of the agenda of the GADS3 Contract Quarterly Review.

3.1.3 Weekly Status Meetings

The Contractor shall meet weekly with the COR and GTM, as part of the weekly status meeting required for the base contract, to provide a status on task activities, task management issues, and any other task-related information that the Government needs to know in order for the Contractor to successfully perform the requirements of the AASC task order. Meetings may be attended by the DERT Deputy Director, the DERT Council Coordinator, or others as required, to identify required end user functionality. The Contractor shall use a PowerPoint briefing deck to deliver the AASC weekly agenda, meeting topics, and any supporting data (“AASC Weekly Status Briefing”) (AASC DEL 3.1-001). Briefing decks should be concise and generally consist of one (1) to three (3) slides. Meetings can take place on-site at the Government facility or via teleconference or WebEx. The Government may determine that weekly status meetings include additional DME task order projects, depending on the size and complexity of the projects.

3.1.4 Contractor Quality Control

The Contractor shall adhere to the GADS3 Quality Control Plan (QCP) that is submitted as part of the GADS3 contract proposal.

3.1.5 Task Order Start-Up Meeting

The task order start-up meeting shall take place as part of the agenda of the GADS3 Contract Start-Up Meeting.

3.1.6 Project Management

The Contractor shall meet all project management requirements as stated in the base contract Section 6.6. The Contractor shall use NIEHS-provided project management software to define and track application development phases in a transparent manner with the Government. NIEHS maintains environments that are available to the Contractor to develop and manage project tracking, ticket tracking, knowledge repositories, and workflows. These currently include:

The Contractor shall not use Internet-based or corporate web sites/portals to full this requirement. For security reasons, this requirement must be fulfilled using NIEHS network-confined tools or software.

3.1.7 Knowledge Management Portal

Within 30 calendar days of the task order award, the Contractor shall begin utilizing the Knowledge Management Portal that it has established under the GADS3 contract for posting all AASC project documentation and deliverables.

3.2 Application Design and Development

The contractor shall develop functionality within the GFDT to utilize the NIH Electronic Research Administration (eRA) Intent to Pay (ITP) web service to connect to IMPAC II, correctly change the application status code, send confirmation/error emails, log application status code change confirmations or errors in each record and to the funding plan, and create a new report that displays confirmation/error information to the user. The Contractor shall update all GFDT documentation as required to capture system changes, including the GFDT Technical Design Document, the GFDT Extract/Transformation/Loading (ETL) process document, GFDT User Manual, and the GADS application inventory.

3.2.1 Collaboration with eRA on AASC Design

The Contractor shall communicate with staff from eRA to determine the best method for implementing the ITP web service within GFDT. This includes assessing whether several applications are changed at once or individually; the frequency with which applications are submitted (on-demand or nightly), and other recommendations or lessons from existing ITP web service users.

3.2.2 Process and Design Documentation

The current workflows and business process are provided in Appendix A. The Contractor shall document the To-Be AASC Business Process (AASC DEL 3.2-001) that supports the concept workflow provided in Appendix B. The Contractor shall provide a Requirements Definition Document (AASC DEL 3.2-002) outlining the detailed requirements. The Contractor shall develop system design documentation to deliver the business functionality, including changes needed to the Solution Architecture Document (AASC DEL 3.2-003). The documentation shall include a solution overview, technical considerations, configuration management, physical architecture diagram, and other items as needed.

3.2.3 Report Design

The Contractor shall develop a new AASC report:

· Story: As Council Assistant, I need to confirm that the correct assignments have been made in the Intent to Pay Module of IMPAC II.

· Story: As a DERT staff person, I need to know what assignments have been made recently.

· The report will be available from the GFDT Report section.

· The user can identify report content using filters for dates (start/end), council round (dropdown), funding plan name (dropdown or keyword search).

· The report outputs shall be in Microsoft Excel format.

· The report name will be included in the output file name, along with the date created.

· A separate worksheet in the report will include the name of the person who generated it, the time and date generated and any parameters (filters) used to create the report.

· New status codes shall appear in the existing interface with no new pages anticipated.

· Variables include: Fiscal Year (FY), Council Round, Applid, grant #, PI Name, PI Institution, Project Title, funding plan date, Status change date, any error messages logged from IMPAC II associated with that Applid.

· Sort by date last approved (last approved by the Chief, GMO).

3.2.4 Application list requirements

· The Status code on the application list will be changed to the “To be paid” status.

3.2.5 Additional Design Requirements

· Each transaction shall be logged both at the application record level and as part of the funding plan.

· The workflow shall accommodate a manual update option if something is needed the same day.

· Roles and permissions will be updated, as needed.

· The process shall be initiated when the Final Funding Plan approval is reached. Currently this final funding plan approval resides with the Chief GMO.

3.3 Testing, User Acceptance Testing, and Release

The Contractor shall conduct testing, user acceptance testing, and release per the requirements stated in the base GADS3 contract Section 7.2. The Contractor shall deliver a User Acceptance Test Plan (DEL DME.C.7.2-2), a Test Report (DEL DME.C.7.2-3), Release Notes (DEL DME.C.7.2-4), and a Release Package (DEL DME.C.7.2-5).

4.0 CONTRACT TYPE:

The Government anticipates awarding a labor hour task order.

5.0 PLACE OF PERFORMANCE:

There are no additional clauses applicable to this section of the task order beyond those in the base contract.

6.0 HOURS OF OPERATION:

There are no additional clauses applicable to this section of the task order beyond those in the base contract.

7.0 PERIOD OF PERFORMANCE:

The total period of performance for this task order shall be for a base period of twelve months and two six-month option periods. This task order also includes the clause at FAR 52.217-8, Option to Extend Services.

8.0 DELIVERABLES/DELIVERY SCHEDULE:

9.0 GOVERNMENT FURNISHED PROPERTY, EQUIPMENT, AND SERVICES:

There are no additional clauses applicable to this section of the Task Order beyond those in the base contract.

10.0 CONTRACTOR FURNISHED PROPERTY, EQUIPMENT, AND SERVICES:

There are no additional clauses applicable to this section of the Task Order beyond those in the base contract.

11.0 SECURITY:

There are no additional clauses applicable to this section of the Task Order beyond those in the base contract.

12.0 TRAVEL:

There are no additional clauses applicable to this section of the Task Order beyond those in the base contract.

13.0 PACKAGING, PACKING, AND SHIPPING INSTRUCTIONS:

There are no additional clauses applicable to this section of the Task Order beyond those in the base contract.

14.0 DATA AND INTELLECTUAL RIGHTS:

There are no additional clauses applicable to this section of the Task Order beyond those in the base contract.

15.0 INSPECTION AND ACCEPTANCE CRITERIA:

There are no additional clauses applicable to this section of the Task Order beyond those in the base contract.

16.0 ACCOUNTING AND APPROPRIATION DATA:

Funds are available for this task order.

17.0 KEY PERSONNEL:

Certain skilled experienced project management and/or technical personnel are essential for accomplishing the work to be performed:

· Written and verbal communications skills to clearly articulate conditions of success for work tickets and create scenarios for user acceptance testing

· Maintenance of program schedules and deliverables completed according to Government requirements

· Management of service level agreements and/or performance metrics as key metrics of success for contract performance

· B.S. or B.A. degree. Two years of related experience may be substituted for the education degree requirement established for this labor category.

· Minimum of 2 years experience developing applications that integrate with or utilize the NIH IMPAC II system.

· Minimum 2 years demonstrated experience working with Agile, and/or Continuous Delivery approaches and best practices

· Demonstrated experience writing test cases and test plans, executing test cases, investigating potential defects, logging defects, reporting test results, and organizing and participating in test plan walkthroughs

· Bachelor’s degree in Information Systems, Information Technology, Computer Science, Engineering, Mathematics, or related field. Two years of related experience may be substituted for the education degree requirement established for this labor category.

18.0 INVOICING:

Emails that contain invoices sent to the CO and the COR for review and approval must contain, in the email header, the name of this task order “AASC”. There are no additional clauses applicable to this section of the task order beyond those in the base contract.

Appendix A: Current Workflow

· Once the GFDT tool sends an automated email to the Division alerting them that the final step of funding plan approval (after the Chief, GMO approves) is complete, the Council Coordinator logs into the Intent to Pay (ITP) eRA module.

· For applications that went to Early Council Concurrence (ECC)

1. The Council Coordinator searches the module to identify records that require updates.

2. The Council Coordinator sets the “Set Council Recom Code” to “1”, to be considered for funding (Figure 1)

3. They set the “Intent to Pay Code to “Yes”

4. They save the update

· For applications that did not go to ECC

1. The Council Coordinator sets the “Set Intent to Pay Code” to “Yes”

2. They save the update

· For R56s:

1. The records are handled manually.

2. Some of the Grants Management Specialists mark the record as “Intent to Pay”, others ask the Council Coordinator to do it.

· For records where the fiscal year needs to change,

1. The Council Coordinator changes the fiscal year associated with the application.

2. They change the “Set Intent to Pay Code” to “yes”

3. They save the update

· Typically, there would be 30+ funding plans per year with anywhere from 3 to 50+ applications listed. The total number of applications funded per year is approximately 1300.

· Typically, the Council Coordinator completes the reassignments within 3 business hours

Figure 1: screen shot from the Intent to Pay module

Appendix B: Concept To-Be Workflow Trigger event: Once the funding plan is complete (i.e., the funding plan is approved by the Chief GMO, which is the last step in the funding plan approval process), the automated process should begin:

a. An email is sent to the division with a link to the funding plan.

b. AASC executes the eRA ITP web service for all the applications on the funding plan and an appropriate eRA system account to update the Intent to Pay module within IMPAC II. eRA supports an ITP Web Service guide that describes required input parameters (six variables), output values (2 variables), and error messages (18 variables).

c. AASC handles different cases as described in Appendix A, that is specific needs for Early Council Concurrence, R56 mechanisms, and Fiscal Year changes.

d. AASC compiles all received data for a given funding plan into one email message with a .csv or .xls file type.

i. Sends the message to the Council Coordinator, with ccs to Deputy Director roles, cc GMB Chief and FMB roles.

ii. Includes a list of applications that were successfully set and a list of applications that were not, with error codes received.

1. Variables include: Fiscal Year (FY), Council Round, Applid, grant #, PI Name, PI Institution, Project Title, funding plan date, Status change date, any error messages logged from IMPAC II associated with that Application

2. The title of the appended file shall be “AASC Confirmation mm.dd.yy.csv”

3. The file shall include a “parameters” tab that includes the date the report was generated, the name of the funding plan, and that it was automatically generated.

iii. Includes tailored subject and message depending on whether and which error codes were received for the batch of applications on the funding plan (to provide a clear indicator to the Council Assistant if a manual update is required).

e. Other steps in the process include:

i. AASC logs the confirmation in the database to each record (this may require new field in the GFDT architecture; or it may be possible to add to an existing comment field).

ii. AASC displays the new status code for the application when it is being shown to GFDT users.

iii. Users can run a report to get details on what changes were made at what time (see section 3.2.3. above).

image1.png