RPA Phase 2 Solicitation SB Set Aside Schedule 70.pdf

19AQMM21R0293

SOLICITATION/CONTRACT/ORDER FOR COMMERCIAL ITEMS

OFFEROR TO COMPLETE BLOCKS 12, 17, 23, 24 & 30

1. REQUISITION NUMBER

5. SOLICITATION NUMBER

19AQMM21R0293

2. CONTRACT NO. 3. AWARD/EFFECTIVE DATE 4. ORDER NUMBER 6. SOLICITATION ISSUE

DATE

07/26/2021

7. FOR SOLICITATION

INFORMATION CALL:

a. NAME

Katherine Lugo

b. TELEPHONE NUMBER (No collect calls)

c. EMAIL Weakley-LugoKF@state.gov

8. OFFER DUE DATE / LOCAL

TIME

CODE LMAQM

OFFICE OF ACQUISITION MANAGEMENT (A/LM/AQM)

PO BOX 9115, ROSSLYN STATION

US DEPARTMENT OF STATE

ARLINGTON, VA 22219

9. ISSUED BY UNRESTRICTED OR X SET ASIDE: % FOR

X SMALL BUSINESS

HUBZONE SMALL

BUSINESS

SERVICE-DISABLED

VETERAN-OWNED

SMALL BUSINESS

WOMEN-OWNED SMALL BUSINESS (WOSB)

ELIGIBLE UNDER THE WOMEN-OWNED

SMALL BUSINESS PROGRAM

EDWOSB

8(A)

NAICS: 541511

SIZE STANDARD:

10. THE ACQUISITION IS

SEE

SCHEDULE

11. DELIVERY FOR FOB DESTINATION

UNLESS BLOCK IS MARKED

12. DISCOUNT TERMS

13a. THIS CONTRACT IS

RATED ORDER UNDER DPAS

(15 CFR 700)

13b. RATING

RFQ IFB X RFP

14. METHOD OF SOLICITATION

CODE15. DELIVER TO CODE16. ADMINISTERED BY

FACILITY

CODE

CODE

Contact Duns Telephone No.

17a. CONTRACTOR/

OFFEROR

CODE18a. PAYMENT WILL BE MADE BY

GLOBAL FINANCIAL SERVICES CENTER, CHARLESTON,

SOUTH CAROLINA

PO BOX 150008; Fax To: 1-866-483-3436

ATTN: OFFICE OF CLAIMS

CHARLESTON, SC 29415-5008

17b. CHECK IF REMITTANCE IS DIFFERENT AND PUT SUCH ADDRESS IN

OFFER SEE ADDENDUM

18b. SUBMIT INVOICES TO ADDRESS SHOWN IN BLOCK 18a UNLESS BLOCK BELOW IS

CHECKED

19. ITEM NO. 20. SCHEDULE OF SUPPLIES/SERVICES

(Use Reverse and/or Attach Additional Sheets as Necessary)

21. QUANTITY 22. UNIT 23. UNIT PRICE 24. AMOUNT

See Line Items Section

25. ACCOUNTING AND APPROPRIATION DATA 26. TOTAL AWARD AMOUNT (For Govt. Use Only)

27a. SOLICITATION INCORPORATES BY REFERENCE FAR 52.212-1, 52.212-4. FAR 52.212-3 AND 52.212-5 ARE ATTACHED. ADDENDA ARE ARE NOT ATTACHED

27b. CONTRACT/PURCHASE ORDER INCORPORATES BY REFERENCE FAR 52.212-4. FAR 52.212-5 IS ATTACHED. ADDENDA ARE ARE NOT ATTACHED

28. CONTRACTOR IS REQUIRED TO SIGN THIS DOCUMENT AND RETURN ____ COPIES TO

ISSUING OFFICE. CONTRACTOR AGREES TO FURNISH AND DELIVER ALL ITEMS SET FORTH

OR OTHERWISE IDENTIFIED ABOVE AND ON ANY ADDITIONAL SHEETS SUBJECT TO THE

TERMS AND CONDITIONS SPECIFIED.

29. AWARD OF CONTRACT: REF. _____________________________ OFFER

DATED _________________ . YOUR OFFER ON SOLICITATION (BLOCK 5)

INCLUDING ANY ADDITIONS OR CHANGES WHICH ARE SET FORTH HEREIN,

IS ACCEPTED AS TO ITEMS:

30a. SIGNATURE OF OFFEROR/CONTRACTOR 31a. UNITED STATES OF AMERICA (SIGNATURE OF CONTRACTING OFFICER)

30b. NAME AND TITLE OF SIGNER (TYPE OR PRINT) 30c. DATE SIGNED 31b. NAME OF THE CONTRACTING OFFICER (TYPE OR PRINT) Katherine Lugo

31c. DATE SIGNED

AUTHORIZED FOR LOCAL REPRODUCTION

PREVIOUS EDITION IS NOT USABLE

STANDARD FORM 1449 (REV. 02/2012)

Prescribed by GSA - FAR (48 CFR) 53.212

CGFS : : CGFS

19.

ITEM NO.

20.

SCHEDULE OF SUPPLIES/SERVICES

21.

QUANTITY

22.

UNIT

23.

UNIT PRICE

24.

AMOUNT

32a. QUANTITY IN COLUMN 21 HAS BEEN

RECEIVED INSPECTED ACCEPTED, AND CONFORMS TO THE CONTRACT, EXCEPT AS NOTED: _________________________________

32b. SIGNATURE OF AUTHORIZED GOVERNMENT

REPRESENTATIVE

32c. DATE 32d. PRINTED NAME AND TITLE OF AUTHORIZED GOVERNMENT

REPRESENTATIVE

32e. MAILING ADDRESS OF AUTHORIZED GOVERNMENT REPRESENTATIVE 32f. TELEPHONE NUMBER OF AUTHORIZED GOVERNMENT

REPRESENTATIVE

32g. E-MAIL OF AUTHORIZED GOVERNMENT REPRESENTATIVE

PARTIAL FINAL

33. SHIP NUMBER 34. VOUCHER NUMBER 35. AMOUNT VERIFIED

CORRECT FOR

COMPLETE PARTIAL FINAL

36. PAYMENT 37. CHECK NUMBER

38. S/R ACCOUNT NUMBER 39. S/R VOUCHER NUMBER 40. PAID BY

41a. I CERTIFY THIS ACCOUNT IS CORRECT AND PROPER FOR PAYMENT 42a. RECEIVED BY (Print)

41b. SIGNATURE AND TITLE OF CERTIFYING OFFICER 41c. DATE

42b. RECEIVED AT (Location)

42c. DATE REC'D (YY/MM/DD) 42d. TOTAL CONTAINERS

STANDARD FORM 1449 (REV. 02/2012) BACK

Line Item Summary

Solicitation Number:

19AQMM21R0293

Contract Number: Title: RPA MVP Date of Solicitation:

Line Item No.

Description Quantity Unit Unit Price Total Cost

001 Base Period- 6 months Firm Fixed Price Sprints

This CLIN includes all tasks, labor, and travel required for the successful completion of the services detailed in the SOO.

Type of Contract Pricing:

Doc Ref No:

Delivery Date FOB:

Destination

Funding Information:

1.00 LT

002 Optional Option for Task Seven ATO- FFP for the base period Type of Contract Pricing:

Doc Ref No:

Delivery Date FOB:

0.00

1001 Option One- 6 months This CLIN includes all tasks, labor, and travel required for the successful completion of the services detailed in the SOO.

Type of Contract Pricing:

Doc Ref No:

Delivery Date FOB:

Destination

Funding Information:

1.00 LT

1002 Optional Option for Task Seven ATO- FFP for Option Period One Type of Contract Pricing:

Doc Ref No:

Delivery Date FOB:

0.00

2001 Option Two- 6 months This CLIN includes all tasks, labor, and travel required for the successful completion of the services detailed in the SOO.

Type of Contract Pricing:

Doc Ref No:

Delivery Date FOB:

Destination

Funding Information:

1.00 LT

2002 Optional Option for Task Seven ATO- FFP for Option Period Two Type of Contract Pricing:

Doc Ref No:

Delivery Date FOB:

0.00

3001 Option Three- 6 months

This CLIN includes all tasks, labor, and travel required for the successful completion of the services detailed in the SOO.

Type of Contract Pricing:

Doc Ref No:

Delivery Date FOB:

Destination

Funding Information:

1.00 LT

3002 Optional Option for Task Seven ATO- FFP for Option Period Three Type of Contract Pricing:

Doc Ref No:

Delivery Date FOB:

0.00

Line Item Summary

Solicitation Number:

19AQMM21R0293

Contract Number: Title: RPA MVP Date of Solicitation:

Line Item No.

Description Quantity Unit Unit Price Total Cost

4001 Option Four- 6 months This CLIN includes all tasks, labor, and travel required for the successful completion of the services detailed in the SOO.

Type of Contract Pricing:

Doc Ref No:

Delivery Date FOB:

0.00

4002 Optional Option for Task Seven ATO- FFP for Option Period Four Type of Contract Pricing:

Doc Ref No:

Delivery Date FOB:

0.00

Section A - Solicitation/Contract Form

1.1 - TYPE OF CONTRACT

This is a firm fixed price contract total small business set-aside off of GSA Schedule 70.

1.2 - INSPECTION & ACCEPTANCE and INVOICING OF SPRINTS

The contractor shall be paid upon the completion of each sprint upon its acceptance and verification by the Contracting Officer’s Representative (COR of the Sprint Certification Package and Artifacts). Invoices shall be submitted at the end of each sprint in accordance with the delivery schedule as established in the Performance Work Statement.

Upon Contractor delivery and Government acceptance of each sprint, the Government shall pay 75 percent of the fixed-price of the sprint. Upon the successful delivery and acceptance of within the POP the Government shall pay the Contractor the remaining 25 percent of the fixed-price of each sprint withheld at the time of each Sprint delivery. In the event the Contractor delivers later than the set POP, the price for the delivery of the bots shall be 75 percent of the fixed-price for each sprint. The Government will continue to pay 75 percent of the fixed-price of each sprint until successful delivery and acceptance by the Government of the deliverables.

Full Payment is contingent on the following deliverables being accepted at the end of performance for each option as detailed below:

Base Period:

1. Migration of existing eight automations that were developed with UiPath automation software to SIO’s UiPath Orchestrator production environment, with adoption of user stories in intended production environment(s) and accepted by the Product Owner.

2. Alternative Analysis

3. Identification of no less than 10 new service center user stories for future automation.

4. All existing bots built during the Pilot shall be fully functional and documented in the Azure devops environment code repository.

5. Project Artifacts and documentation including requirements, discovery assessments, process maps, solution designs, technical designs, architecture, security, test plan(s), test scripts, test results, implementation plan, training, user guides, lessons learned as part of a post-implementation review.

6. An MVP (bot with just enough features to be usable by early customers who can then provide feedback for future produce development) for each of the following bots:

i. Automate Account Services

ii. Automate Data Transfer

iii. User Account Exception Request Customer Alert

iv. Data Validation Scans of Active Customer Tickets

v. Microsoft Endpoint Configuration Manager (MECM) Customer Reach Back

vi. Automate Account Deletion

vii. Automate Endpoint Refresh Files Transfer

viii. Create External Account

ix. Automate Validated Data Retention

x. Automate Programmatic Access

Option Periods 1-4:

At the beginning of the options if exercised the government and contractor shall come to a mutually agreeable definition of done to receive full payment at the end of the option period, understanding that at the end of the entire contract the conditions the "definition of done" shall be met.

Notwithstanding when the bots are delivered and accepted by the Government, the Contractor remains obligated to deliver and failure to deliver within a commercially reasonable time from contract award will be deemed a condition endangering contract performance and may provide grounds for default termination.

1.3 - Definition of Done

A sprint will only be considered completed when all objectives under that sprint have been met.

The resulting contract will be considered successful when the following outputs have been delivered:

- Initial Discovery Phase assessments for each user story detailing conclusions drawn from process demonstrations, in-person interviews of subject matter experts, and reviews of current state processes and procedures documentation.

- Enhancement of existing eight automations that were developed with UiPath automation software.

- Migration of existing eight automations that were developed with UiPath automation software to SIO’s UiPath

Orchestrator production environment, with adoption of user stories in intended production environment(s) and accepted by the Product Owner.

- Automated processes based upon CCS’ 10-12 user stories identified in this document using automation software products.

- Identification of no less than 10 new service center user stories for future automation.

- Develop and deploy an initial digital version of the product in both development and production environments, respectively.

- Conduct usability research with end users to determine whether the success criteria were met.

- Determine and document what is necessary to create the levels of efficiency through the solution(s), if successful, or a plan to pivot to a different solution if unsuccessful.

- Integration of service center, usability, automations executions logs metrics with a performance monitoring platform.

- Resiliency of automations through connection of endpoints, e.g., API integrations.

- Efficiency and capacity gained report based on success metrics.

- Project Artifacts and documentation including requirements, discovery assessments, process maps, solution designs, technical designs, architecture, security, test plan(s), test scripts, test results, implementation plan, training, user guides, lessons learned as part of a post-implementation review.

- Retrospective of achievements, lessons learned, recommendations for future automations, and what is necessary to continue or scale adoption.

2.0 - Statement of Objectives

A. BACKGROUND

CCS is modernizing and centralizing DOS Tier 1 service desks. Robotic Process Automation (RPA) is seen as a promising technology that can be implemented to gain efficiencies to existing processes and mitigate the need for additional labor as CCS consolidates 19+ duplicative helpdesks/service desks. Ideally, this new technology will be built with an Industry Partner versed in both RPA and service center modernization. If successful, the existing automations and named user stories candidates will be used to support increased tickets volume as the other service desks are centralized into a unified IT service center.

B. OBJECTIVE

The objective of this requirement is to assist the Department of State, Information Resource Management Bureau Operations, Offices of Systems Integration (SIO) and Consolidated Customer Support (CCS) with the implementation of automations that support IT service center functions (Tier 0-2). These Offices require that the contractor is versed in User Experience (UX) design thinking, process improvement, and Agile software development. These methodologies will be applied toward the requirements for:

- Enhancement and sustainment of eight existing automations,

- Future automation software development efforts, and

- Automation(s) implementation support working with Operations and Maintenance teams.

To achieve this goal, quality partners must provide expertise to

- Evaluate and assess the “as-is” environment,

- Recommend process improvements,

- Demonstrate an understanding of the Department’s technical landscape for digital service solutions, and

- Determine whether a viable solution may be feasible for implementation in the Department.

The contractor must be able to establish and execute a framework using digital service techniques to identify and solve essential business needs through the development, testing, and release of automations to end users. The completion of the scope for this contract/task order will provide information necessary in the development of an acquisition strategy for the procurement or full implementation of a new technology solution.

C. PROBLEM STATEMENT

SIO and CCS seek ways to automate routine processes in a user-oriented and intuitive manner to increase high-value staff work and reduce manual work, redundancy, and rework. To meet key business objectives efficiently and effectively in the DOS organization, CCS advocates for the design, co-creation, and implementation of automation that will provide value to stakeholders, customers, and users. CCS requires a project cost analysis including KPIs such as “annualized capacity gained” for each user story.

CCS has encountered several technical challenges with full implementation of existing automations. UiPath Orchestrator, maintained in Azure Enterprise Application Integration Services (EAIS) platform is awaiting ATO to support production for UiPath RPA.

This is the platform that “houses” the Orchestrator. For the UiPath Orchestrator Production environment to be “ready,” the EAIS platform needs to be ready too. Previously CCS developed production-ready bots during a proof-of-concept pilot despite the lack of Orchestrator. However, this project experienced several issues in provisioning and configuring bots without Orchestrator.

Additionally, automations were only developed for in-office work on desktop workstations due to the need to perform work under two separate credentials. Per the DOS policy, users cannot use “privileged accounts for actions that can be completed using non-privileged accounts.” Thus, a service center technician cannot perform “user” type work in ITSM system while logged in under Administrative credentials to access Active Directory tools. Thus, automations are not often accessed unless users are reporting into the office environment. Existing and future automations must be developed for remote work.

Current State Constraints:

1. Without Orchestrator, publishing new or updated processes is much more of a challenge.

2. Without Orchestrator, access to extended libraries from UiPath, other third-party providers like Microsoft, or libraries developed for reuse across DOS are currently being downloaded from the Official UiPath online package sources. If we have Orchestrator, all the libraries needed can be hosted there and the bots will have access to all the libraries needed from this central repository which would be internal to OpenNet.

3. With no central console monitoring the bots’ operations must be done by inspecting the UiPath log files on each robot machine.

With Orchestrator, the monitoring of bots, inspection of bot logs would be done centrally through the Orchestrator console. The logging levels of each bot in Orchestrator could also increase/decrease, which will be helpful when it comes to troubleshooting issues.

4. Promoting code through its lifecycle from DEV to TEST to PROD is much easier with Orchestrator in place. For example, once code is tested in DEV, the packages are exported from the DEV Orchestrator and imported into the TEST Orchestrator, and after testing, into the PROD Orchestrator. Without the Orchestrator this process is manual, and prone to human error.

5.UiPath License Allocation/Provisioning/Management would be easier to manage and monitor with Orchestrator. Currently, UiPath must provision our licenses as “standalone,” which means that we must go directly to UiPath to reprovision the licenses when we want to move them from one environment to the other.

6. There are many other Orchestrator features like Queues, Assets, Credential Store Integration, Folders, Analytics Dashboards that can be very helpful for an enterprise scale RPA program. TBD as this point, but a factor to consider in the future – particularly if DOS is to progress toward unattended automations.

7. Overall, not having an Orchestrator makes it difficult and inefficient to scale up RPA. Most DOS RPA teams using UiPath automation software are doing so on a few dedicated devices, and locally on workstations or GO Desktops (EMD) with a limited set of users. To enable automations that will support service desk functions and high tickets volumes, automations must be accessible to more than just a few users. DOS expects that the Contractor will develop automations that are scalable and available to multiple users simultaneously.

8. Currently, technicians must log into the network under user credentials with a session open, and then RDP into Active Directory tools under Administrative credentials on the same device. On remote endpoints, such as laptops, and because of current security policy, when a technician pulls their user PIV to switch from one persona to the other, they are logged out of the remote workstation, making it impossible for a bot to continue executing its tasks. To enable automations that support service center operations, DOS expects that the Contractor will support inter-Bureau technical collaborations including, but not limited to, requesting exceptions to existing security policies that may not yet account for new technologies, but may with proper education and demonstration of automation technologies.

There are eight existing automations that require Enhancement and Sustainment:

- Data Transfer Request Bot

- Password Reset Bot

- Data Access Request Bot

- User Account Exception Request Bot

- Automated Endpoint Testing Bot

- Customer Engagement and Follow-Up Bot

- Account Disablement Bot

- Distribution List Modification Bot

There are at least eleven user story candidates identified for Development and Modernization to create process efficiencies with the goal to reduce the “time to fulfill,” “time to resolve.” Most service center incident resolution and request fulfillment tasks are completed manually.

- Automate Account Services

- Automate Data Transfer

- User Account Exception Request Customer Alert

- Data Validation Scans of Active Customer Tickets

- Microsoft Endpoint Configuration Manager (MECM) Customer Reach Back

- Automate Account Deletion

- Automate Endpoint Refresh Files Transfer

- Create External Account

- Automate Validated Data Retention

- Automate Programmatic Access

Once in production, it is important to measure return on investment and automations performance. There are key service center automation and usability metrics the contract shall track, including but not limited to,

- Number of uses per automation per (hour, day, month)

- Automation usage by time of day

- Automation task completion duration (seconds)

- Number of automations uses (by user)

- Number of automations uses (by workstation name)

- Errors per bot

- Bot errors per endpoint (or user)

D. Required Tasks

The following shall be performed during each option and can be translated into epics and user stories for sprint planning for each option period.

Task 1: Analysis of Alternatives (AoA): Assisting (IRM/OPS/SIO) to determine which modern technologies are feasible to implement in environment.

Objective: SIO will have a deep understanding of platforms and technology tools available in the market that are most advantageous in the technology environment. Coach SIO and CCS through the process of discovering tradeoffs for alternative platform solutions, to include short and long-term implications. Provide guidance and best practices on automation Center of Excellence (CoE) processes.

As an added benefit, part of this scope includes analysis required in theFederal Source Code Policywhich applies to all federal agencies (with limited exceptions).

Tasks:

- Clearly identify of an appropriate DOS/IRM/OPS problem that can be solved with a modern technology platform.

- Analysis of opportunities, constraints, and assumptions for each technology

- Implications of software language options (commonality and adoption in the marketplace)

- Open architecture availability

- Deployment strategies (Analyze platform constraints and support)

- Likelihood of continuous integration

- Availability of pre-existing Open-Source Software that meets or can be modified to meet SIO needs

- Availability of custom-developed source code to be Open-Source Software and available to the public, as referenced in theFederal Source Code Policy

- Impact on SIO IT environment

- Ease to fix when technology solution is not performing

- Cost models: investment, operating, support, ROI, life cycle

- Security considerations

- Design and user experience (UX) considerations

- 508 compliance considerations

- Records and legal constraints

- Support constraints

- Other customers’ satisfaction with the technology

- Industry best practice suggestions from technology leaders

- Implementation time frame implications

- Market Intelligence Around Providers

- Pricing structures

- Vendor based considerations

- Adequate competition considerations

- Vendors’ implementation capabilities

- Risk of potential vendor lock-in

- Small business vendor opportunities

- Constraints of funding availability

Deliverables: Matrix of factors behind decision making that takes into account total cost of ownership (licensing models, data lock-in, cost to transfer), technical complexity/staffing requirements (i.e., requisite certifications per proposed technical solution), technical debt, ability to integrate/build APIs (what connectors and packages are available) and vendor lock-in.

Task 2: Discovery and Design

Objective: SIO and CCS SMEs in collaboration with the Industry Partner will determine how to solve problems through digitalization, utilize user centered design techniques and agile product management methods to create an approach to making the Help Desk more efficient, codified through metrics. The appropriate metrics will measured at the beginning of the project and after the pilot users have used the resulting attended bots for an iteration. Any corrections to the approach will be documented and used to revise the user stories for the next iteration.

Tasks:

- Conduct user story discovery to determine a digital solution to the agency problem and end user goals for this activity.

- Create hypothesis statement(s) that can be tested by the prior to release of capabilities.

- Create a backlog of user stories in addition to those provided by CCS and listed in the SOO.

- Codify the objectives in metrics used to improvements in Help Desk efficiency.

The successful solution, at a minimum, shall also include the following best practices as highlighted in the digital service playbook:

Understand what stakeholders need

The contractor shall begin this digital service project by exploring and pinpointing the needs of process operators who will use the service, and the ways the service will fit into their daily routine. The vendor shall continually test the products with end users to ensure delivery is focused on meeting their needs.

In delivery of this effort the contractor shall:

Early in the project, the contractor shall engage with current and prospective users of the service (SMEs and pilot team).

Use a range of qualitative and quantitative research methods to determine people’s goals, needs, and behaviors.

Develop and test mockups or prototypes of solutions with real people, in the field if possible.

Document the findings about user goals, needs, behaviors, and preferences.

Share findings with the team and agency leadership.

Create a prioritized list of tasks the user is trying to accomplish, also known as "user stories" to be utilized in the agile development process.

During development, continuously user-test capabilities to ensure they meet user needs.

Measure the resulting efficiencies with the pilot team and project those efficiencies on the entire help desk to show the result of using bots.

Task 3: Development of User Oriented Automation Products

Objective: Use agile software development methods to develop automations and release to end users.

Tasks:

- Utilize an agile development method to write and manage epics, user stories, acceptance criteria.

- Conduct iteration retrospectives, release planning, backlog grooming, and other common activities associated with iterative design and agile methodologies.

- Implement best practice methods for automated testing and code reviews.

- Work with (DOS/IRM/OPS/CCS) leadership to develop or manage continuous integration, code management processes, security, 508 compliance, privacy or any other agency policies that need to be incorporated to release the product into the production environment.

- Use CCS provided UiPath development environment in the cloud to build the solution up to the point where it integrates with other systems.

- Deploy the system to the OpenNet production environment for (DOS/IRM/OPS/CCS) testers and pilot users.

- Test solution with end users and conduct user research activities.

- Create and track metrics to determine whether the delivered solution meets end users’ needs and solves agency problem statement to some degree.

- As a result of the feedback provide recommendations on what should be modified in future versions of the product

The successful solution, at a minimum, shall also include the following best practices as highlighted in the digital service playbook:

Address the whole experience, from start to finish

The contractor shall holistically account for the different ways people will interact with our services, including the actions they take online, through a mobile application, on a phone, or in person. Every encounter — whether it's online or offline — should move the user closer towards their goal.

In delivery of this effort the contractor shall: Understand the different points at which people will interact with the service – both online and in person.

Identify pain points in the current way users interact with the service and prioritize these according to user needs.

Design the digital parts of the service so that they are integrated with the offline touch points people use to interact with the service.

Develop metrics that will measure how well the service is meeting user needs at each step of the service.

Make it simple and intuitive

Successful delivery of this contract requires that the services of and products delivered will not be stressful, confusing, or daunting.

Therefore, the contractor shall build and release automations that are simple and intuitive enough that users succeed the first time, unaided.

In delivery of this effort the contractor shall:

Use a simple and flexible design style guide for the service. Use UiPath best practices to build production-quality bots for the pilot team.

Use the design style guide consistently for related digital services.

Give users clear information about where they are in each step of the process.

Follow accessibility best practices to ensure all people can use the service.

Provide users with a way to exit and return later to complete the process.

Use language that is familiar to the user and easy to understand.

Use language and design consistently throughout the service, including online and offline touch points.

Use data to drive decisions

At every stage of a project, the contractor shall measure how well our service is working for our users. This includes measuring how well a system performs and how people are interacting with it in real-time. These metrics shall be reported to the (DOS/IRM/OPS/ CCS) Program Managers to find issues and identify which bug fixes and improvements should be prioritized. Along with monitoring tools, a feedback mechanism should be in place for people to report issues directly.

In delivery of this effort the contractor shall:

Monitor system-level resource utilization in real time.

Monitor system performance in real-time (e.g., response time, latency, throughput, and error rates).

Track concurrent users in real-time, and monitor user behaviors in the aggregate to determine how well the service meets user needs.

Provide metrics which may be published internally.

Provide metrics which may be published externally.

Task 4: Retrospective: What worked, what didn’t, what to do next

Objective: Following each iteration, the (DOS/IRM/OPS/CCS) government and contractor team comes together to understand from a project viewpoint to identify improvement actions.

Tasks:

- Conduct a project retrospective activity that analyzes data gathered during. performance around goals, timeline, budget, major events, and success or failures

- Determine what roadblocks were mitigated and which ones still exist that need to be addressed.

- Provide or update the Product Backlog for scaling this effort through continuous design and agile processes.

- Ensure all system documentation, user stories, acceptance criteria and test scripts are finalized.

Task 5: Initial Environment System Configuration and Implementation

Objective: Contractor shall provide IRM with a secure, stable, records compliant, commercial collaboration, process enabled automations.

The contractor shall design automations for maximum interoperability to ensure flexibility in leveraging the system for future Bots.

The contractor shall configure the automations to support tiered code-release separation and quality assurance by implementing an integrated end-to-end testing methodology.

The contractor shall seek to configure off-the-shelf aspects of the selected platform before recommending a customized coding approach.

The contractor shall develop automations in such a manner as to leverage maximum re-use and sharing across the platform.

The contractor shall ensure that all changes with impacts to other applications on the platform are minimized. Where such changes are required, they shall be documented, and the release coordinated well in advance with the appropriate product owner and development team.

The contractor shall provide incremental documentation through sprint cycles that results in full technical documentation or configuration for all software development efforts and product releases with all information necessary to document processes, procedures, code artifacts, and/or policies that were implemented in the creation of the development work.

Once any functionality is released, it shall be the responsibility of the contractor to fix at their own expense any resulting bugs or system defects that are related directly to the contractor’s implementation, code, or design. The fix of these bugs shall not affect other scheduled user stories, deliverables, or releases and shall be at no cost to the government. This requirement for fixing bugs or defects is not considered maintenance or enhancements to automations.

Task 6: CCS Automation Enhancement and Sustainment Support

The Contractor shall collaborate with SIO to support promotion pipeline activities, including but not limited to maintenance and ongoing availability of all CCS automations. The Contractor shall develop an Operations and Maintenance (O&M) Support Plan that details the Contractor’s plan to migrate all bots into SIO’s environment(s), including incident resolution procedures. The Contractor shall deliver the Bot O&M Support Plan to the DOS Product Owner and COR for review and approval.

The Contractor shall operate within multiple CCS/SIO environments within IRM including, but not limited to the following environments:

- Development

- Staging/Testing

- Production

Each DOS environment may be divided into sub-environments as determined by DOS. The Contractor shall ensure that all software associated with maintaining and operating the bots is delivered and tracked on DOS owned and operated version control systems. The Contractor shall ensure COTS software is licensed appropriately. DOS shall provide the Contractor with access to such systems.

The Contractor shall provide DOS automations maintenance to include corrective maintenance; adaptive maintenance; perfective maintenance; and preventative maintenance to ensure all bots are continuously available, function correctly, provide current information features and provide the best possible user experience.

The Contractor shall:

1. Provide SIO production support for bots

2. Provide non-production environment support during normal DOS business hours (7 am – 9 pm EST).

3. Identify requirements for additional functionality within the bot infrastructure. The Contractor shall include the results of this activity in an Application Infrastructure Recommendations Report appended to the Monthly Status Report.

4. Monitor system and Service Level Agreement (SLA) metrics via DOS approved monitoring tools and provide a real-time dashboard available to all program stakeholders.

5. Provide configuration management and change control with DOS and other teams as directed.

6. Perform upgrades and patches within pre-defined maintenance windows.

7. Define and administer users, user groups, and user access.

The Contractor shall be responsible for the break-fix of any bots hosted in the CCS environment affected by changes made to the environment.

Deliverables: The Contractor shall provide an SLA Monitoring Plan that defines how SLA metrics will be monitored throughout the performance of the requirements, including the automated testing tools and automated SLA testing scripts that shall be used. The Contractor shall provide the SLA Monitoring Plan to the DOS PM/COR for review and approval. Upon approval, the Contractor shall implement SLA monitoring IAW the approved plan and establish an SLA Dashboard that provides real time SLA metrics data available to all program stakeholders. The Contractor shall provide an automations logs report on a biweekly basis which shall capture data as specified in the Deliverable Metrics/SLAs.

*If we adopt unattended Bots Task 7 shall apply (See section 2 for instructions on pricing)*

· Optional Option Task 7- AUTHORITY TO OPERATE (ATO) The Contractor shall develop and maintain Application/Infrastructure security documentation in support of achieving and maintaining an ATO.

The Contractor shall:

1. Comply with DOS ATO process.

2. Use DOS FISMA control tracking system as the security documentation repository to complete and update security controls.

3. Coordinate with the DOS security office and adhere to its policies.

4. Complete all DOS required training (i.e. on-boarding, security, ethics, etc.) as well as provide certificates of completion to the

COR.

5. Create, as directed, a wide Variety of National Institute of Standards and Technology (NIST) SP800-Series security artifacts per

FISMA requirements for DOS systems.

6. Manually review upcoming due dates for security artifacts and work with system maintainers or appropriate representatives to ensure artifacts are updated annually.

7. Support, and develop annual attestation documentation in conjunction with the system maintainer and business owner.

8. Peer review security artifacts and provide feedback to document authors.

9. Coordinate and lead quarterly familiarization exercise for Contingency Plan and Incident Response Plan.

10. Provide security documentation reporting to PMs, Information Security officers (ISO), and others.

11. Update existing Privacy Impact Analysis (PIA), System Security Plan (SSP) documents and create new PIA documents as required in support of DOS apps.

12. Update ATO package as necessary

Deliverable:

A. ATO Package Documentation

E. TRANSITION-OUT PLAN

The Contractor shall prepare a Transition-Out Plan. The Contractor’s plans shall define transition efforts to be conducted, documentation, and information to be transferred to and reviewed with other relevant contractors. Transition-Out Plan will be reviewed by and require approval of the DOS Program Manager and COR.

The Transition-Out Plan shall, at a minimum, address the following:

1. Transition schedule.

2. Phase-Out Migration Checklist (Contractor format).

3. Delivery of final deliverables; artifacts; DOS documentation, including DOS Standard Operating Procedures (SOP), Tooling

Support Plan, and Developers Guide; and lessons learned.

4. Delivery of software, release/code versions, processes, artifacts, and documents supporting each task area of the PWS in a format that is usable by DOS.

5. Outputs of automated test results and pass/fail results.

6. Delivery of performance, security, and browser testing results.

7. Training of relevant Government and Contractor personnel.

8. Communication on, and delivery of, security concerns such as badges, tokens, and accounts,

9. Plan for ensuring that, prior to termination or completion of this effort, the

Contractor/Subcontractor does not destroy any information in any form received from DOS, or gathered/created by the Contractor while performing this effort without prior written approval by DOS PM/COR.

1. An orientation phase to introduce the successor Provider personnel, programs, and users to the incumbent team, explaining tools, methodologies, and business processes

2. Providing signed transition agreements in the DOS designated format.

The Contractor shall archive all final documentation and materials in a secure location as directed by the DOS COR.

Deliverables:

A. Transition-Out Plan

F. TRANSITION-OUT SERVICES

In accordance with the Government-approved transition-out plan, the Contractor shall assist the Government in implementing a complete transition from this contract to a new support provider.

This shall include formal coordination with Government staff as well as successor staff and management. The Contractor shall also include delivery of copies of all DOS artifacts, software licenses, existing policies and procedures, data, source code, baseline metrics and statistics, and any additional DOS documentation or information.

Successful transition is defined as 100% completion of all work defined in the Government approved Transition-Out Plan.

Upon the completion of the transition period, the Contractor shall provide closeout certifications that include a statement that the contract is complete, all deliverables have been provided, all services are complete, and there are no outstanding contractual issues.

Deliverables:

A. Closeout Certifications

G. EXAMPLE ITERATION PLAN

Pre-Sprint 0 (30 days): Onboarding Activities

- Verify/Await Contractor Clearances

- Provision User and Administrative Accounts

- Assess Software Licensing Needs and Procure Where Needed

- Discovery and Assessments of Environments E.G., FRAME (Dev/Test) And Production

- Assess Required Development Tools

Deliverables:

Project Management Plan, Assessment Report of Discovery for Infrastructure and Tools

Sprint 1 (30 Days): Learn Environment and Business (Discovery)

- Meet with SMEs For Existing Automations and Proposed User Stories

- Identify and Scope User Stories

- Identify Key Service Center Automation Metrics

- Analyses of Alternatives

- Enhance the Eight (8) Existing User Stories and Begin Test of Added Capabilities

- Start Development of Proposed User Stories

- Begin Unit Testing in Development Environment for Existing Automations

- Retrospective

Deliverables:

Process Discovery Artifacts, Process Maps, Result of SME Interviews and Demonstrations, List of Administrative, Resource, and Technical Blockers, Analysis of Alternatives Based on Discovery Process

Sprint 2 (30 Days): Work Within Bot Development Lifecycle

- Continue Meet with SMEs To Identify Service Line Dependencies and Blockers to Success

- Scope User Stories

- Begin Functional Test for Enhanced Automations and Solution and Technical Design New User Stories

- Develop and Demonstrate for Government No Less Than Four (4) Enhanced Automations and Two (3) New Automations

- Deliver Automations for User Acceptance Testing

- Deploy Automations in Production working with SIO

Solution Design Documents per User Story, Technical Design Documents per User Story, Draft Architecture and Test Plan(s), Test Scripts

Sprint 3 (30 Days): Optimize the Business

- Identify 5–10 Potential New User Stories to Reduce the Service Desk Agent to Human Interaction By 10 Percent

- Continue Unit and Functional Iterative Testing for All Automations

- Provide Test Results and Scope of Any Rework

- Develop and Demonstrate for Government Remaining Four (4) Enhanced Automations and Two (3) More New

Automations

- Deliver No Less Than Four (4) New Automations for User Acceptance Testing

- Continue to Deploy Enhanced, Existing and New Automations in Production working with SIO

Completed Test Scripts, Updated Architecture, Updated Test Plan, Draft User Guide, Draft Training Manual, Work Instructions

Sprint 4 (30 Days): Wrap Up Testing and Defect Remediation

- Identify 5–10 More New User Stories to Continue Making SDAs Job Easier

- Complete User Acceptance Testing for Remaining Automations

- Deliver Backlog of Remaining User Stories (Automations) to Government

- Prepare to Deploy in Production (Orchestrator)

- Support Promotion Pipeline Activities Between SIO and CCS

Additional Completed Test Scripts, Final Architecture, Final Test Plan, O&M Support Plan User Guide, Training Manual, Work Instructions, Test Analysis Report SLA Monitoring Plan, and SLA Report

Sprint 5 (30 Days): Production Deployment Pipeline and Support

- Complete User Acceptance Testing for Remaining Automations

- Deliver Backlog of Remaining User Stories (Automations) to Government

- Prepare to Deploy in Production (Orchestrator)

- Support Promotion Pipeline Activities Between SIO and CCS

- Manage Production Issues, if encountered

Updates to any Final Documentation, Additional Completed Re-Test Scripts, Post Implementation Review and Lessons Learn Report, Updated Inter/Intra-Office Concept of Operation, and Efficiency or Capacity Gained Report Based on Help Desk Automation Metrics.

The Contractor shall provide the COR with Monthly Progress Reports in electronic form in electronic format. These reports shall reflect data as of the last day of the preceding Month.

The Monthly Progress Reports shall cover all work completed during the reporting period and work planned for the subsequent reporting period. The report shall include metrics of success as described under Tasks 3 and 6 of this document.

The report shall also identify any problems that arose and a description of how the problems were resolved. If problems have not been completely resolved, the Contractor shall provide an explanation including their plan and timeframe for resolving the issue. The report shall also include an itemized list of all Electronic and Information Technology (EIT) deliverables and their current Section 508 conformance status. It is expected that the Contractor will keep in communication with DOS accordingly so that issues that arise are transparent to both parties to prevent escalation of outstanding issues.

The Sprint Reports shall cover the user stories and functionality agreed upon for the sprint period. The Sprint Report shall also cover any risks and issues. Sprint Reports shall be submitted at the end of each sprint. The Contractor and the Government shall agree upon a sprint cadence during the kickoff meeting.

Prior to each Sprint, the Contractor and the COR shall agree to a Definition of Done to be completed within the upcoming sprint(s), including any required deliverables. The Contractor shall not invoice for any iteration until and unless the COR has accepted the agreed to Definition of Done.

Deliverable:

A. Monthly Progress Report B. Sprint Reports

2.2 - BOT-METRICS/SLAs

The government will fill in the blanks upon award the contractor shall propose numbers in their PWS.

The contractor shall be responsible for fixing all systems, development, and services issues whether they were originally attributed to them or not.

System Availability: The Contractor shall provide an aggregate uptime for all bot components of no less than ____%. When this outcome is achieved an external entity shall be able to log into the environment, execute build and deploy jobs in the development enclave, and observe the results of those jobs. Services that are faulted due to an external entity shall have trouble tickets logged with the responsible party, with all outage time attributable to this team until the ticket is logged with the responsible entity.

Services that are unavailable due to upstream maintenance must have an outage notification to all DOS stakeholders prior to the maintenance window for attribution to the upstream team.

The Contractor shall have access to the Government’s published maintenance window times and dates upon award. An automated test, IAW the approved SLA Monitoring Plan, and the logged reports of execution, including timing details, of that test shall be provided in the SLA Report.

Development Environment Availability: The Application Development Environment shall be available during all working hours.

An external entity shall be able to log into the environment, execute build and deploy jobs in the development enclave, and observe the results of those jobs with no less than ___% availability. An automated test, IAW the approved SLA Monitoring Plan, and the logged reports of execution, including timing details, of that test shall be provided in the SLA Report.

Service Availability: All deployed services shall be available and functional to serve user requests at no less than ____% availability.

An external entity shall be able to access and receive a successful response to all services deployed to this platform at any time. As available on a per service basis sample transactions or health check endpoints that are exposed to external entities shall be evaluated to determine if the response is successful. Services that are faulted due to an external entity shall have trouble tickets logged with the responsible party, with all outage time attributable to this team until the ticket is logged with the responsible entity. An automated test, IAW the approved SLA Monitoring Plan, with an execution frequency of no more than ____seconds, and the logged reports of execution, including timing details, of that test shall be provided in the SLA Report.

Any faulted services attributed to an external entity shall include a record of the trouble ticket that was issued to the responsible party.

This record shall include the time that it was filed, and if resolved, the time of resolution. Any maintenance window outages shall include a record of the notification that was distributed to DOS Stakeholders, and the time which the record was distributed.

Service Uptime: Services run on this platform shall remain online no less than ____% of the time. All scheduled services will remain active and able to serve requests. An automated test, IAW the approved SLA Monitoring Plan, with an execution frequency of no more than _____ seconds, and the logged reports of execution, including timing details, of that test shall be provided as a report to the

DOS.

All scheduled services and their associated uptime shall be provided in the SLA Report.

Service Reachability: Services on this platform shall be reachable by outside entities no less than _____% of the time. All required routing and proxying services are correctly functioning and forwarding traffic. Services that are faulted due to an external entity shall have trouble tickets logged with the responsible party, with all outage time attributable to this team until the ticket is logged with the responsible entity. Services that are unavailable due to upstream maintenance must have an outage notification to all DOS stakeholders prior to the maintenance window for attribution to the upstream team.

The Contractor shall have access to the government’s published maintenance windows times and dates upon award. An automated test, IAW the approved SLA Monitoring Plan, and the logged reports of execution, including timing details, of that test shall be provided in the SLA Report.

2.3 - DELIVERABLES

1. PWS Deliverables-The contractor shall provide access to the entire code repository and deliver working and deployed code. They shall also provide a library of all deliverables they detail in their iteration plan in their submitted PWS.

a. Monthly Progress Reports- As described in G. Example Iteration Plan, the Contractor shall provide the COR with Monthly Progress Reports in electronic format. These reports shall reflect data as of the last day of the preceding Month.The Monthly Progress Reports shall cover all work completed during the reporting period and work planned for the subsequent reporting period. The report shall include metrics of success as described under Tasks 3 and 6 of this document.

The report shall also identify any problems that arose and a description of how the problems were resolved. If problems have not been completely resolved, the Contractor shall provide an explanation including their plan and timeframe for resolving the issue. The report shall also include an itemized list of all Electronic and Information Technology (EIT) deliverables and their current Section 508 conformance status.