Draft RFP HC101325R0008.pdf

SEE ADDENDUM

(No Collect Calls)

HC101325R0008 28-Jul-2025

b. TELEPHONE NUMBER

667-890-6253

8. OFFER DUE DATE/LOCAL TIME

12:00 PM 26 Aug 2025

5. SOLICITATION NUMBER 6. SOLICITATION ISSUE DATE

AUTHORIZED FOR LOCAL REPRODUCTION

PREVIOUS EDITION IS NOT USABLE

STANDARD FORM 1449 (REV. 2/2012)

Prescribed by GSA – FAR (48 CFR) 53.212

(TYPE OR PRINT)

(SIGNATURE OF CONTRACTING OFFICER)

ADDENDA ARE

26. TOTAL AWARD AMOUNT (For Gov t. Use Only )

23.

CODE 10. THIS ACQUISITION IS

SUCH ADDRESS IN OFFER

17b. CHECK IF REMITTANCE IS DIFFERENT AND PUT

BELOW IS CHECKED

TELEPHONE NO.

HC10139. ISSUED BY

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

7. FOR SOLICITATION

INFORMATION CALL:

a. NAME

HAYDEN MICKELSON

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

(TYPE OR PRINT)

30b. NAME AND TITLE OF SIGNER 30c. DATE SIGNED 31b. NAME OF CONTRACTING OFFICER

30a. SIGNATURE OF OFFEROR/CONTRACTOR 31a.UNITED STATES OF AMERICA

0 27a. SOLICITATION INCORPORATES BY REFERENCE FAR 52.212-1. 52.212-4. FAR 52.212-3. 52.212-5 ARE ATTACHED.

25. ACCOUNTING AND APPROPRIATION DATA

1. REQUISITION NUMBER

20.

ADDITIONAL SHEETS SUBJECT TO THE TERMS AND CONDITIONS SPECIFIED.

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

SOLICITATION/CONTRACT/ORDER FOR COMMERCIAL ITEMS

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

(BLOCK 5), INCLUDING ANY ADDITIONS OR CHANGES WHICH ARE

SET FORTH HEREIN, IS ACCEPTED AS TO ITEMS:

. YOUR OFFER ON SOLICITATION

28. CONTRACTOR IS REQUIRED TO SIGN THIS DOCUMENT AND RETURN

% FOR:SET ASIDE:UNRESTRICTED ORX

SMALL BUSINESS

17a.CONTRACTOR/ CODE FACILITY

OFFEROR CODE

DISA/DITCO-SCOTT-PS82

2300 EAST DRIVE

BLDG 3600

SCOTT AFB IL 62225-5406

18a. PAYMENT WILL BE MADE BY CODE

RATED ORDER UNDER

DPAS (15 CFR 700)

13a. THIS CONTRACT IS A

13b. RATING

CODE15. DELIVER TO CODE HC1047 16. ADMINISTERED BY

12. DISCOUNT TERMS11. DELIVERY FOR FOB DESTINA-

TION UNLESS BLOCK IS

MARKED

SEE SCHEDULE

14. METHOD OF SOLICITATION

RFQ IFB RFPX

DISA ACQ/SD/SD2

6914 COOPER AVE

FT MEADE MD 20755-7088

PUNEETINDER MANN

TEL: 667-891-2927 FAX:

FAX:

TEL: SERVICE-DISABLED

VETERAN-OWNED

SMALL BUSINESS

8(A)

HUBZONE SMALL

BUSINESS

SIZE STANDARD:

$34,000,000

NAICS:

541512

X

OFFER DATED

29. AWARD OF CONTRACT: REF.

DELIVER ALL ITEMS SET FORTH OR OTHERWISE IDENTIFIED ABOVE AND ON ANY

COPIES TO ISSUING OFFICE. CONTRACTOR AGREES TO FURNISH AND

EMAIL:

TEL:

31c. DATE SIGNED

SEE SCHEDULE

SCHEDULE OF SUPPLIES/ SERVICESITEM NO. QUANTITY UNIT UNIT PRICE AMOUNT

24.22.21.19.

WOMEN-OWNED SMALL BUSINESS (WOSB)

ELIGIBLE UNDER THE WOMEN-OWNED

SMALL BUSINESS PROGRAM

EDWOSB

32g. E-MAIL OF AUTHORIZED GOVERNMENT REPRESENTATIVE

SOLICITATION/CONTRACT/ORDER FOR COMMERCIAL ITEMS

(CONTINUED)

PAGE 2 OF145

ACCEPTED, AND CONFORMS TO THE CONTRACT, EXCEPT AS NOTED: ______________________________________________________

32a. QUANTITY IN COLUMN 21 HAS BEEN

RECEIVED INSPECTED

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

37. CHECK NUMBER

FINALPARTIALCOMPLETE

36. PAYMENT35. AMOUNT VERIFIED

CORRECT FOR

34. VOUCHER NUMBER

FINAL

33. SHIP NUMBER

PARTIAL

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

41a. I CERTIFY THIS ACCOUNT IS CORRECT AND PROPER FOR PAYMENT

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

42a. RECEIVED BY (Print)

42b. RECEIVED AT (Location)

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

STANDARD FORM 1449 (REV. 2/2012) BACK

Prescribed by GSA – FAR (48 CFR) 53.212

AUTHORIZED FOR LOCAL REPRODUCTION

PREVIOUS EDITION IS NOT USABLE

SEE SCHEDULE

20.

SCHEDULE OF SUPPLIES/ SERVICES

21.

QUANTITY UNIT

22. 23.

UNIT PRICE

24.

AMOUNT

19.

ITEM NO.

HC101325R0008

Section SF 1449 - CONTINUATION SHEET

PERFORMANCE WORK STATEMENT

PERFORMANCE WORK STATEMENT (PWS)

Award/Mod Effective Version Date Solicitation

Award

Contract Number: To Be Determined (TBD) Task Order Number: TBD Contractor Name TBD Tracking Number: TBD Follow-on to Previous Contract and Task Order Number:

HC104720C0004

1. Contracting Officer’s Representative (COR).

a. Primary COR. See DITCO Additional Text G1 - Points of Contact

b. Alternate COR. See DITCO Additional Text G1 - Points of Contact

c. Property Administrator See DITCO Additional Text G1 - Points of Contact

2. Contract or Task Order Title. Integrated Defense Enterprise Acquisition System (IDEAS) – Tier 2 / Tier 3 Support

3. Background. The Defense Information Systems Agency (DISA), a Combat Support Agency, engineers and provides command and control capabilities and enterprise infrastructure to continuously operate and assure a global net-centric enterprise. DISA directly supports joint warfighters, national level leaders, and other mission and coalition partners across the full spectrum of operations. DISA’s Procurement Services Directorate (PSD) purchases telecommunications and information technology (IT) products and services for the military, other Defense Agencies, and Federal Organizations.

To fulfill its mission, DISA PSD requires contract writing systems for both telecommunications and IT (also referred to as Traditional) contracting. DISA PSD established the Enterprise Business Modernization (EBM) project in January 2004 to meet the following objectives for DISA PSD’s contract writing system:

Create a single integrated procurement solution that is uniformly implemented and readily accessible worldwide.

Share consistent data, services, and processes across business functions and systems applying the tenets and principles of net-centricity.

Provide accurate and easily retrievable information for all PSD contracting functions and associated external users.

Reduce operational costs while increasing procurement efficiency.

The resultant contract writing system capability, IDEAS-O&M, was deployed in 2009 for DISA PSD’s telecommunications products and services contracting. The modernized solution for IDEAS is called IDEAS-Next Generation (NG) is under development in an effort to make the existing code and process modernization with the Department of Defense (DoD) mandated Business Enterprise Architecture (BEA), specifically the Procurement Data Standards (PDS) and Purchase Request Data Standards (PRDS) that support the Procure to Pay (P2P) business model.

IDEAS is being developed using an agile development methodology taking advantage of the Appian Business Process Management (BPM) commercial off-the-shelf (COTS) tool.

The current IDEAS solution is built on the Appian platform and BPM is hosted in the Impact Level 5 (IL5) Appian Government Cloud (AGC), a commercial cloud offering that sits atop of the Amazon Web Services Government Cloud, West region. In summary, the underlying BPM that supports the application, the database on which the business data resides, and the technical architecture supporting all are contained in the AGC. The AGC environment consists of 4 instances to manage the development and support effort.

Development – used by the developer team to configure the Appian BPM tool to resolve business issues.

Staging – used to perform low level testing taking advantage of an agile development mindset.

Performance – is a higher testing environment with “close to real” data which can be used for end-to-end testing, testing of resource intensive IDEAS features, user acceptance testing (UAT), and perhaps as a fail-over when there is a need to shut down the Production environment for maintenance.

Production – the layer the user sees as part of their business requirement (NG and O&M).

Any legacy functionality of the IDEAS-O&M solution that still needs to communicate with other legacy systems still in use at DISA takes advantage of a Data Integration (DI) layer used to move data from the various P2P systems. The DI relies on a series of web services that either receive or transmit data amongst the systems. This layer resides in the DISA offered Stratus cloud environment although it also connects to the IDEAS database in AGC to store its data schemas. The technical environment in the Stratus cloud includes a Virtual Operating Environment supporting the Production Suite for the operators, and a Staging Suite for system functional verifications and UAT. There is no end user capability in the DI; only web services moving data between systems.

The DI will be sunset when all legacy contracts are transitioned out of IDEAS-O&M and into IDEAS NG.

The Scrum development process and sprint cycles are currently managed using an Appian BPM Artifact Management Tool developed exclusively for IDEAS. If DISA mandates a different tool to manage the technical effort, the contractor shall use the new tool as provided by the Government.

4. Objectives: The objective of this requirement is to provide solution definition, software development, testing, integration, production support, and expertise for IDEAS and the DI Layer. This includes providing support and expertise for: DoD Business Enterprise Architecture, Telecommunications Contracting, System Integrations, Data Warehousing, transactions occurring between systems, user training, governance documentation, data migration support (e.g., import/export, scripting) and reporting capabilities.

IDEAS system integration support shall include accommodating the Office of Defense Pricing, Contracting and Acquisition Policy (DPCAP) Application Program Interface (API) as it evolves, maintaining existing integrations (e.g., Federal Procurement Data System – Next Generation (FPDS), Defense Logistics’ Agency (DLA) Global Exchange (GEX)/EDA, etc.), and establishing new or updated integrations for IDEAS-NG as DISA modernizes its other business systems (e.g., Service Now, Oracle Financials integration using the PDS and PRDS as they apply to the flow of contract data in the DoD P2P process, development and support of non-standard (non PDS/PRDS) interfaces between integrated systems.)

IDEAS software development support shall include all phases of the Software Development Lifecycle (SDLC), including concept development, planning, requirements definition and analysis, systems design and development, coding and testing, deployment, implementation, integration, troubleshooting, security posture, documentation, and software application maintenance necessary to sustain and/or modify the system baseline. Responsibilities include managing the IDEAS’ code baseline as it interacts with users, the hosted environment, and external systems. The IDEAS baseline may change because of changes to Laws, Regulations and Policies (LRPs), End to End architectures (e.g., P2P), Operational Activities (OAs), contracting processes, user preference, latent defects, change requests, security requirements, or to accommodate new releases of the COTS products used by the system (e.g., Appian BPM, Red Hat Linux, Web Logic, Apache, etc.) or expansion of the types of business processes supported by IDEAS.

IDEAS production support shall include troubleshooting and resolving user problems and identification of opportunities to improve processes or business process models in the system.

IDEAS reporting capabilities shall be augmented / developed to support customer requirements and or to improve the availability, timeliness, and quality of IDEAS data. The reporting capabilities were created using Appian’s BPM tool and enhanced by Java software code. Reports access data through associated system components such as web and integration software. It is imperative to minimize or even eliminate all specialty code that may negatively impact regular upgrades to the Appian BPM version. The Government’s goal is to strive to stay within no more than 2 major versions away from the current Appian BPM.

The contractor shall work closely with other members of the team to include IDEAS engineers, Government subject matter experts (SMEs), stakeholders, Government test team, hosting, security, and end-users.

5. Scope. The contractor shall provide software development support for IDEAS-O&M and IDEAS-NG in the DISA’s Business Systems Portfolio Management Office (PMO). The contractor shall provide a solution, product consulting, and programming to:

(1) Implement new system capabilities by the configuration of COTS software.

(2) Implement change requests.

(3) Sustain deployed capabilities in the IDEAS-O&M and IDEAS-NG solution by rapidly troubleshooting and resolving software issues impeding the execution of deployed contracting capability (i.e. correct Tier 3 defects);

(4) Provide technical expertise to ensure high availability of the IDEAS applications to meet the DISA mission; and,

(5) Receive and respond to problems reported by the users (i.e. correct Tier 2 incidents). This support shall address issues with the core Appian BPM components in the IDEAS solution, as well as its integration components in Java.

The IDEAS platform has approximately 500-person primary contracting user base, which includes contracting personnel in three general time zones, Europe – 10% (which includes Southwest Asia), continental United States – 80%, and Pacific region – 10%. Each field office has technical support personnel who are responsible for most Tier 1 activities (e.g., client PC operation, network connectivity). The contractor shall provide remote tier 2 and 3 technical support to all users worldwide. Different types of contracting users will conduct different types and amounts of transactions in the contracting systems, and consequently will have different levels of impact on support.

IDEAS also maintains an internet-facing capability used by commercial activities outside the DoD network (DoDNet). All contractors use a user-id/password combination or a Common Access Card (CAC) if they have one, to login. Each login attempt is further secured by a two-factor authentication (2FA) process where a one-time code is sent to the contractor’s email and the contractor must input this code into IDEAS to gain access. Access is available from the commercial internet i.e. outside DoDNet

The contractor shall modernize and sustain the existing application, system integrations, and reporting capabilities.

These areas are comprised of distinct key application and operational capabilities that include:

Telecommunications Contracting Orders against Indefinite Delivery (ID) Contracts/Indefinite Quantity (IQ) Blanket Purchase Agreement (BPA) Inquiry, Quote, Order (IQO)

System Integrations Financial Accounting Management Information System (FAMIS) Federal Procurement Data System – Next Generation (FPDS-NG) Contract Opportunities (SAM.gov) Clause Logic Service (CLS) Data Variable Transaction Set (DVTS) (Contractual Online Procurement System (COPS))

COPS Inventory of Service (IOS) (COPS) DLA Global Exchange Services (GEX)) Procurement Data Standard (PDS) Validation Service Order Management Conformed Contract View (CCV) Telecommunications Service Request (TSR) Services (DISA Storefront (DSF)) DISA Marketplace (DMP)/DISA Storefront (DSF) Notification Service (Contract Support System (CSS)/Status of Acquisition Message (SAM)/Telecommunications Status Information (TSI)) Global Exchange (GEX) Standard Financial Information Structure (SFIS) Service (US Standard General Ledger (USSGL)) Data Migration Service (Electronic Document Management System (EDMS)/(CSS)) AutoFile Service (EDMS/CSS) PRDS Service (DISA Financial Management Ledger) Electronic Document Access (EDA) Worldwide Online System (WWOLS)

Reporting and Metrics (Any reports existing in O&M should be available in NG unless specifically identified by PSD as no longer needed) Standard Reports Ad-Hoc Reports and Queries Data Warehouse

The IDEAS requirement consists of the following task areas:

Task Area 1 - Task Order Management Task Area 2 - Software Support for IDEAS NG Task Area 3 – Production Support for IDEAS NG Task Area 4 - System Administration and Cybersecurity Task Area 5 - Software Support for IDEAS O&M (Optional Task) Task Area 6 - Migration Support to Cloud or Software as a Service Platform (Optional Task) Task Area 7 - DI Server Support Task Area 8 – IDEAS Next Generation (NG) Task Area 9 – Training

The Government may require surge support during the base or any option period, and surge modifications will be within the scope of the contract and provide increased support for the defined task areas of this PWS. Surge support over the life of the contract will not exceed 50% of the contractor’s total proposed cost/price for the base and all option periods, excluding any six-month extension of services pursuant to Federal Acquisition Regulation (FAR) 52.217-8.

6. Performance Requirements. The contractor shall use a Government provided software tool (e.g., JIRA) to effectively manage and execute the agile Scrum methodology to analyze requirements, decompose large requirements into logical sub artifacts, create user stories for Epic (i.e. large encompassing stories that must be decomposed into children stories), level artifacts and technical specifications, coordinate with the appropriate SMEs (both technical and functional) to receive approved acceptance criteria for Epic/Task/Subtask level artifacts, set Story Points and establish a waterline, develop and test software, create test scripts and implement UAT, and keep artifact statuses updated (artifacts are the method for identifying a change with software which will be deployed to Production). To maintain predictable velocity, the contractor shall complete the artifacts directed by the COR in each software sprint, and team members are encouraged to collaborate towards requirements completion. User stories and design documentation shall be maintained within artifact tracking tool. Appian BPM process models and other "source code" level documentation shall include the artifact number, date, name of the developer, and a short summary of every change (i.e. solution provided). The technical release documentation shall trace all changes between original sources (e.g. Change Request number), artifact(s), modules, and test scripts and shall document all changes and procedures necessary to place a given release into production.

Each assigned task will have one or more associated artifacts. The IDEAS software development sprints are typically planned as 2-6 week sprints resulting in monthly software releases. The COR will provide an approved work list detailing the work to be accomplished in each sprint.

The contractor shall serve as an active member of the Change Advisory Board (CAB) and the Configuration/Change Control Board. The contractor is responsible for defining user stories, maintaining the product backlog, and prioritizing the product back-log to streamline the execution of program priorities while maintaining the conceptual and technical integrity of the features or components. The contractor shall collaborate with the development teams from legacy, DI and BPM to ensure the artifact tracking tool (e.g. JIRA) and IT Service Management (ITSM) are actively maintained and reflect the status of each artifact or ticket. The contractor shall also collaborate with contract specialists (CS), contracting officers (KOs) and other key stakeholders to ensure requirements are understood and properly defined so that an appropriate t-shirt size, or level of effort, can be designated for each artifact and story points associated to each user story.

The contractor shall respond to artifacts to change the system configuration and reports. The contractor shall lead the Scrum process and other meetings to define, build, test, document, and deploy updates to the Appian BPM platform.

The contractor shall ensure lead-time for understanding and responding to unique CAB approved requests. The planning for functionality requested by the CAB may include the contractor’s recommendations to minimize rework and cost. If a change is beyond the contractor's capacity to complete in the assigned sprint, the contractor shall provide a detailed implementation recommendation and schedule during the weekly sprint review meetings.

Complex tasks may require additional documentation and coordination prior to coding. These tasks are assigned to a sprint for development of a specification prior to the implementation sprint. The contractor shall work with SMEs to create, and receive approval on, user stories, functional specifications, or technical specifications. Additionally, the contractor shall maintain a software development and product roadmap as defined in subtask 6.1.1 of this PWS.

As legacy application functions transition to IDEAS, the contractor shall provide IDEAS application development support including performing analysis and development using Java Development Kit to support Java and Java Script; maintaining code integrity using Team Foundation, SourceSafe, Subversion or equivalent; maintaining web services using Oracle Web Logic; performing development using cloud-based environments; and subject matter expertise in Scrum development practices. This support is intended to provide integration support between IDEAS and other in-ternal and external business systems.

If a change results in a latent defect found during operation at some future time, and analysis determines the contractor's personnel made the errant change, the defect shall be corrected by contractor personnel without affecting software sprint/release velocity.

The contractor shall work with the appropriate personnel (Program Manager, COR, etc.) to manage assigned work, project estimation, hours worked, status tracking, workload management and activity reporting to management. This is necessary to manage technical resources and effectively plan for release and implement changes to DISA Enterprise Applications. The contractor shall work tickets assigned to them in the order of highest priority and/or sequence. DISA Services Directorate 2 (SD2) uses the Scrum/Agile software development methodology to effectively manage workload and promote software releases into production. Upon receipt of a ticket, the contractor shall effectively communicate with the team and/or customer in order to complete the requirement within the allocated timeframe and/or sprint cycle.

Contractors shall record actions taken on tasks and hours worked on a daily basis using the GTS. On a weekly basis, the GTS will be used to generate status reports that will detail the activities performed, hours worked and the progress made to date. The Program Manager (PM) will submit a consolidated weekly report to the COR.

The contractor shall provide a weekly status report outlining the progress of current and future tasks with completion status. The report shall also identify any issues and risks, dependencies, and/or engineering updates that require Government interaction for resolution and/or impact delivery. The update shall outline what work has been performed, what problems have been encountered that may impact schedule, potential solutions for any problems, and projected tasks for the next week. The update shall also include metrics on the program’s performance with regard to capabilities provided to the customer and the outcome from those capabilities. In addition, the weekly status report shall include proposed changes to the schedule as detailed in the management plan as well as property accountability, technical accomplishments, issues and risks, and planned activities for the next reporting period. Any issues requiring Government response or action shall be brought to the Government’s attention no later than the same calendar day upon identification, and status captured in weekly reports.

This report shall contain the total number of open tickets by system name. The report shall identify how many tickets were opened during the work week and how many tickets were closed during the work week. The report shall identify any ticket that was not closed based on the criticality and resolution times specified in the performance standards of this PWS. The contractor shall be flexible with evolving reporting requirements to support emerging guidelines provided by DoD, DISA, management and DISA customers. In addition, this report shall contain all open tickets by system name listed in order of priority starting with highest priority, and further sorted such that the earliest ticket of a given priority is at the top for that priority grouping. This report shall contain the ticket number, priority level, associated tickets, descriptions, corrective action, date opened and date closed with the user, as well as trend and other data the contractor's analysis suggests would be pertinent. It shall correlate actions taken to other tasks or solutions that resolved similar tickets. If the contractor has detected a trend, this report shall include a brief summary of the trend, associated tickets, pertinent distribution of causes, and recommended corrective action to prevent similar troubles. The contractor shall use their expertise in BPM to recommend changes to form labels, help text, data validation, and process models. The Government will review these recommendations and provide guidance when appropriate. Since the tickets are assigned via the Government tracking system and the contractor shall enter results into trouble tracking system, metrics associated with the responsiveness, quantity, and duration of tickets shall be extracted directly from the trouble tracking system and summarized in the weekly report.

The contractor shall provide Frequently Asked Questions (FAQs) from users to better ensure system flaws are addressed, training materials are provided and the support staff is informed. FAQs shall be categorized by the frequency of occurrence and the amount of time taken to provide resolution to the user. The contractor shall house the user guide and training manual within the IDEAS system for ease of access for users.

The contractor shall develop Standard Operating Procedures (SOPs) for Tier 2 ticket resolution to address FAQs or frequently occurring incidents and problems that can be resolved at the Tier I level. The contractor shall make recommendations to the Government regarding topics that can be resolved with Tier 1 level access and expertise.

6.1. Task 1 – Task Order Management. The contractor shall provide the planning, direction, coordination, and control necessary to accomplish all requirements in this PWS. The contractor shall provide the Government a primary and alternate Point-of-Contact that will serve as the Focal Point for both management and technical matters. The contractor shall attend monthly Program Management Review meetings where the status of the work and associated deliverables are reviewed in the context of the business processes supported by the system.

The Task Order Management Plan (TOMP), submitted as part of the contractor’s proposal, shall be updated as changes occur or upon request from the COR.

The TOMP shall include at a minimum:

Organization Management structure/control (by name and job title) Task Order execution plan

Identification of Non-Disclosure Requirements. All DISA Contractors must execute a DISA-provided contractor non-disclosure agreement (NDA) for all services contracts regardless of award amount. The NDA must be signed within one week of contract/task order award. The DISA contractor is responsible for obtaining and maintaining NDAs for each contractor employee assigned to the contract/task order.

6.1 Deliverables:

Task Order Management Plan Non-Disclosure Agreements

6.1.1 Subtask 1 – Program Reporting. The contractor shall maintain and provide input into an Integrated Master Schedule (IMS). The IMS will align to the PM’s PM monthly sprint schedule and define the specific tasks associated to the items in the product roadmap. Additionally, the IMS shall highlight interdependencies between contractors and tasks that pose a risk to the Government. The IMS shall be updated weekly and reflect the most current state of the development and support efforts.

The contractor shall maintain a software development and product roadmap to plan out new capabilities, functionality changes, system maintenance, and/or product upgrades. The software schedule shall include current sprint, sprint +1, and sprint +2. The contractor shall be up-to-date with development software within 180 calendar days. Thereafter contractor shall be no more than two minor versions behind. The contractor shall provide a roadmap of the artifacts scheduled to be worked on for the next 90 calendar days. Based on the product backlog and change requests, the contractor shall provide a roadmap as far out as possible with data that is available at each sprint. The roadmap shall be updated at the beginning of each monthly sprint when the waterline is established and regularly updated as changes occur. The contractor shall use the roadmap to help articulate issues with staffing, requirements, and prioritization.

The contractor shall provide a weekly status report outlining the progress of current and future tasks for all active tasks with completion status. The report shall also identify any issues and risks, dependencies, and/or engineering updates that require Government interaction for resolution and/or impact delivery. The update shall outline what work has been performed, what problems have been encountered that may impact schedule, potential solutions for any problems, and projected tasks for the next week. The update shall also include metrics on the programs performance with regard to capabilities provided to the customer and the outcome from those capabilities. In addition, the weekly status report shall include proposed changes to the schedule as detailed in the management plan as well as property accountability, technical accomplishments, issues and risks, and planned activities for the next reporting period. Any issues requiring Government response or action shall be brought to the Government’s attention within 60 minutes of identification, and status captured in weekly reports.

The weekly status report shall contain tickets and artifacts received and the actions taken during the reporting period. It shall correlate actions taken to other tasks or solutions that address resolving the reason for the artifact.

Any GTS epics in development should be correlated to program requirements as appropriate. Since the artifacts are assigned via the GTS. Since the artifacts are assigned via the GTS Database and the contractor will enter results into the GTS, metrics associated with the responsiveness, quantity, and duration of the artifacts will be extracted directly from the GTS. The status report shall include a cumulative tally of all artifacts assigned to the most recently completed release that have not been previously reported. This tally shall include the release identifier, total number of artifacts assigned to a release per category, the category (i.e. established within the GTS such as CAB Request, Defect, Requirement), and a total sum of total artifacts across all categories. Further, the report shall contain a sum of artifacts (per category and overall total) that were planned for each sprint (i.e. above the waterline after sprint planning using story points), as well as the sum of artifacts that are accepted in UAT (per category and overall total) and placed into production with the scheduled release. The bottom of the table shall include totals for each column.

This table shall be provided in Microsoft Excel and/or comma separated value format. A notional example is provided below:

Waterline Deployed

Release CAB Defect Requirement Total CAB Defect Requirement Total

10.3 17 4 9 30 17 5 7 29

10.3.1 3 3 3 3

10.4 22 9 4 35 22 9 4 35

Totals 39 16 13 68 39 17 11 67

This report shall contain the total number of open tickets by system name. The report shall identify how many tickets were opened during the work week and how many tickets were closed during the work week. The report shall identify any ticket that was not closed based on the criticality and resolution times specified in the performance standards of this PWS. The contractor shall be flexible with evolving reporting requirements to support emerging guidelines provided by DoD, DISA management and DISA customers. In addition, this report shall contain all open tickets by system name listed in order of priority starting with highest priority, and further sorted such that the earliest ticket of a given priority is at the top for that priority grouping. This report shall contain the ticket #, priority level, associated tickets, descriptions, corrective action, date opened, and date closed with the user, as well as trend and other data the contractor's analysis suggests would be pertinent. It shall correlate actions taken to other tasks or solutions that resolved similar tickets. If the contractor has detected a trend, this report shall include a brief summary of the trend, associated tickets, pertinent distribution of causes, and recommended corrective action to prevent similar troubles. The contractor shall use their expertise in BPM to recommend changes to form labels, help text, data validation, and process models. The Government will review these recommendations and provide guidance when appropriate.

The contractor shall submit the Monthly Status Report (MSR) collating all relevant information from the weekly status report since the previous MSR and other deliverables from other tasks.

6.1.1 Deliverables:

IMS

Software Development and Product Roadmap Weekly Status Report Monthly Status Report Change Request Documentation Configuration Management Plan and Procedures

6.1.2 Subtask 2 – Contract Transition. The contractor shall provide a written Transition-Out Plan 90 calendar days prior to contract expiration. The contractor shall provide all materials and support necessary to accomplish a seamless and expeditious transition of the tasks identified in this PWS to the incoming contractor. The contractor shall deliver a Transition-Out Plan which includes electronic copies of the following: all in-progress working files, historical files for all tasks, Concept of Operation (CONOPS) procedures, and final phase out meeting with Government, incumbent and the new contractor, and documented lessons learned throughout the life of the contract.

The Transition Plan shall be delivered to the Government 90 calendar days before the end of the contract period of performance.

6.1.2 Deliverables

Transition Plan

Deliverables for Task Area One (1):

PWS

Task#

Deliverable Title Format Due Date Distribution/Copies Frequency and Remarks

6.1 Monthly Status

Report (MSR)

Contractor format, Government approved

Due within 14 Calendar days after month end

Email to ACOR, COR, PM, Tech Lead, and Product Owner

Monthly and can consolidate multiple deliverables throughout the PWS into the

MSR.

6.1 Task Order

Management Plan

Contractor format, Government approved

Due with Technical proposal

Email to ACOR, COR, PM, Tech Lead, and Product Owner

Update due as changes occur or upon request from the Government.

6.1 Non-Disclosure

Agreements

Government format Due 5 calendar days of contract award/5 business days after new employee is onboarded to support the contract

Standard Distribution* and email to ACOR, Tech Lead, and Product Owner

Once.

Update(s) as new personnel are onboarded to support the contract

6.1.1 IMS Contractor format, Government approved

Initial due 60 calendar days after contract award then at the beginning of each sprint

Email to ACOR, COR, PM, Tech Lead, and Product Owner

On the Monday following each 2-6 week sprint release

6.1.1 Software

Development and Product Roadmap

Contractor format, Government approved

Initial due 60 calendar days after contract award then at the beginning of each sprint

Standard Distribution* and email to ACOR, PM, Tech Lead, and Product Owner

On the Monday following each 2-6 week sprint release

6.1.1 Weekly Status

Report

Contractor format, Government approved

Initial due 10 calendar days after contract award then every Friday.

Standard Distribution* and email to ACOR, Tech Lead, and Product Owner

Weekly

6.1.1 Change Request

Documentation

Contractor format, Government approved

1st Business Day of the Month

Standard Distribution* Monthly

6.1.1 Configuration

Management Plan and Procedures

Contractor format, Government approved

Initial due 60 days after contract award

Standard Distribution* Once at due date

6.1.2 Transition Plan Contractor format, Government approved

90 calendar days before contract expiration

Standard Distribution* Once at due date

*Standard Distribution: 1 copy of the transmittal letter without the deliverable to the Contracting Officer and assigned Contract Specialist; 1 copy of the transmittal letter with the deliverable to the Primary COR.

6.2. Task 2 – Software Support for IDEAS NG. The contractor shall respond to requirements that are generated by the Government. Artifacts are the method for identifying a change with software, which will be deployed to production. The contractor shall properly record user stories, issue(s), acceptance criteria, testing, and software solutions to create an IDEAS knowledge base within the GTS (e.g., JIRA). The contractor shall follow the SDLC process when completing artifacts to include: requirement decomposition, elicitation, completion of user stories and specifications, development, unit testing, integration testing, and UAT.

6.2.1. Subtask 1 - Software Support. The contractor shall employ the agile Scrum process to define, build, test, document, and deploy updates to the IDEAS. This process agility shall support system change frequency as short as a single day, but typically scheduled for 2 to 6 week sprint cycles. These artifacts may emerge from CAB Change Requests, Requirements based on LRP changes, PMO requirements, or changes to requirements in the system's security posture. Check points are inherent in the agile development process;

however, it is extremely important that new capability software components are uniquely identified during the process. User stories, use cases and/or functional specifications shall capture features to be deployed and will be used by the Government as a basis for testing and acceptance.

The contractor shall attend the Scrum process meetings and other meetings to define, build, test, document, and deploy updates to the Appian BPM platform. The contractor shall ensure lead-time for understanding and responding to unique CAB approved requests. The planning for functionality requested by the CAB may include the contractor’s recommendations in order to minimize rework. If a change is beyond the contractor's capacity to complete in the assigned sprint, the contractor shall provide a detailed implementation recommendation and schedule in the project plan and it will be discussed during the weekly sprint review meetings. These tasks are assigned to a sprint for development of a specification prior to the implementation sprint. The contractor shall create, and receive approval on, user stories, functional specifications, or technical specifications, and may consult with SMEs in the accomplishment of this task.

The contractor shall provide a project plan and employ the agile Scrum process to design the necessary capability.

This design shall include all necessary artifacts and appropriate sizing / complexity documented in artifact tracking tool with the required elements for planning, development, and testing. The project plan shall include logical milestones for the deployment.

In addition, the contractor shall respond upon identification to production support issues that cause work stoppage or operational problems with IDEAS and ensure the Production Suite operates without interruption to functional users.

Software defects that result in work stoppage or impact to business operations shall result in an unplanned software Hot Fix. Correcting defects identified through production support that do not result in work stoppage shall be prioritized and assigned to current sprint or sprint +1 by the Government depending on the impact to business operations. The contractor shall provide production support (i.e. Tier 2) activity in identifying the root cause of production support malfunctions and creating Tier 3 artifacts (i.e. software code changes) to permanently resolve and prevent them. The contractor shall input all actions taken to resolve artifacts into artifact tracking tool. The contractor shall coordinate with the Tier 2 production support team to ensure minimal rework or downtime during software changes and to ensure the Tier 2 activity understands planned system changes. The contractor shall join in UAT for releases to ensure proposed changes are acceptable to the users. The contractor shall provide release notes and, host release reviews for functional users to illustrate system changes.

The primary deliverable of this task is a detailed project plan, release documentation, process models, functional specifications, interface control documents, system configurations, software code, database schemas, system operating manual, and user release notes from this task.

Release documentation shall include a work plan with recurring updates, release test plans, release test results, UAT plan with user test scripts, process models, functional specifications, interface control documents, system configurations, software code, database schemas, system operating manual, request to promote, and user release notes from this task. Release notes, which include all artifacts with associated problem descriptions, solutions, and deployment instructions. The contractor shall provide post release, and additional information regarding outstanding actions, risks, or issues to the Government. This will allow the Government to fully understand the work that has occurred, post release issues, risk, or outstanding actions, and forecast what is being planned for the future. The information shall be provided at the post release meetings (typically held the first business day after a release).

The System Operating Manual shall be provided and capture information sufficient to install, operate, and maintain

IDEAS.

Actual software code shall be installed on the virtual machine architecture currently set up to support IDEAS, thus maximizing efficiency of development, testing, performance, and availability to the customer; and provided as a tagged code segment via the Government managed code repository or delivered on Digital Video Disc or other mutually agreed upon format.

The contractor shall provide user release notes prior to a software release being deployed into the production environment. The release notes shall include a summary of the added functionality, the change requests, bug fixes and associated artifacts included within the release. The user release notes shall be written at the user level and not a technical description of the release. The contractor shall develop, update, and maintain all IDEAS user-facing documentation. This documentation shall be rendered and delivered using standard office applications such as Microsoft (MS) Word, Power Point, Excel, and Visio, as well as other visual presentation applications such as Adobe PhotoShop and TechSmith Camtasia following the Government’s style guides. The contractor shall join in the SDLC along with users and developers to understand user needs, struggles, and system behavior so documentation can be provided that makes the users as productive as possible. Typical engagements and meetings include participating in user training, release reviews, general meetings, and UAT. The contractor shall monitor each release as it approaches UAT to draft release notes from the release plan (e.g. Software Forge, JIRA) for all user visible artifacts. These release notes shall explain the changes visible to the user in language understandable by the user audience, as well as the respective ticket numbers (artifacts, incident, change request, etc.) associated with each item. These notes shall be posted in the specified repository and the Government notified once posted for review and publishing.

The contractor shall initiate a formal request to promote to the Government prior to executing a software release.

The request to promote shall be accompanied by a document that highlights the artifacts to be released, the proposed date and time of the release, the release version, the names of external systems impacted, implications to the security posture, confirmation that all artifacts were tested, deployment instructions, rollback procedures and confirmation that resources needed for the release are scheduled or available. The request to promote requires review and sign-off from the Information System Security Manager (ISSM), technical lead and PM.

The contractor shall ensure compliance to the DPCAP guidance and policy for Telecommunication and Traditional contracting. The contractor shall work closely with contracting stakeholders in order to better understand the business needs. The contractor shall interpret, analyze, and translate Telecommunication and Traditional contracting business needs and problems into requirements. The contractor shall ensure requirements are agreed upon and approved by the contracting stakeholders prior to translating to the technical teams. A specification document shall be used to define contracting requirements, capture stakeholder input, and serve as concurrence between key business stakeholders and the technical teams. The contractor shall provide subject matter expertise to the contracting stakeholders and technical teams when requirements are unclear or non-compliant with DPCAP guidance, inefficiencies exist in business rules, or process flows and to assist with defining level of effort to help facilitate proper prioritization by both the functional and technical teams. Develop and support data migration strategies from systems that are non-compliant with DPCAP to compliant processes within IDEAS. Contractor shall provide documentation and test data supporting interoperability certification within a suite of DPCAP compliant systems. Contractor shall work closely with other systems in the P2P process to ensure interoperability in compliance with DPCAP guidance and policy.

6.2.1.1 Subtask 2 – IDEAS Backlog Support. There is stakeholder interest in reducing the IDEAS Product Backlog, which has been growing considerably due to the need to address higher priority artifacts. The contractor will participate in recurring backlog grooming sessions to identify customer and PMO development priorities.

6.2.1 Deliverables:

Project Plan

Release Documentation Process Models Functional Specifications Interface Control Documents System Configurations Software Code Database Schemas System Operating Manual Request to Promote Document Specification Document

6.2.2. Subtask 3 – Technical Refresh Support. The contractor shall provide support services for changes due to the commercial migration path of the Appian COTS software. This will involve analyzing existing process models against new Appian releases for incompatibilities and superseded features. Once approved by the Government, the contractor shall refactor the necessary applications to ensure continued stability.

This refactoring shall be incorporated with the IDEAS release schedule and follow the SDLC process for integration and UAT of refactored code.

Deliverables for Task Area Two (2):

Deliverable Title

Format Due Date Distribution/Copies Frequency and Remarks

6.2.1 Project Plan Contractor format, Government approved

6 weeks after award of contract

Email to ACOR, COR, PM, Tech Lead, and Product Owner

1x every 2-6 week sprint

6.2.1 Release

Documentat ion

Contractor format, Government approved

Last day of each 2- 6 week sprint

Email to ACOR, COR, PM, Tech Lead, and Product Owner

Each Sprint

6.2.1 Process

Models

Contractor format, Government approved

Last day of each 2- 6 week sprint

Email to ACOR, COR, PM, Tech Lead, and Product Owner

Each Sprint

6.2.1 Functional

Specificatio ns

Contractor format, Government approved

Last day of each 2- 6 week sprint

Standard Distribution* And email to the Tech Lead and Product Owner

Each Sprint

6.2.1 Interface

Control Documents

Contractor format, Government approved

Last day of each 2- 6 week sprint

Email to ACOR, COR, PM, Tech Lead, and Product Owner

Each Sprint

6.2.1 System

Configurati ons

Contractor format, Government approved

Last day of each 2- 6 week sprint

Standard Distribution* and email to the Tech Lead and Product Owner

Each Sprint

6.2.1 Software

Code

Contractor format, Government approved

Last day of each 2- 6 week sprint

Standard Distribution* and email to the Tech Lead and Product Owner

Each Sprint

6.2.1 Database

Schemas

Contractor format, Government approved

Last day of each 2- 6 week sprint

Standard Distribution* and email to the Tech Lead and Product Owner

Each Sprint

6.2.1 System

Operating Manual

Contractor format, Government approved

Last day of each 2- 6 week sprint

Email to ACOR, COR, PM, Tech Lead, and Product Owner

Each Sprint

6.2.1 Request to

Promote document

Contractor format, Government approved

Last day of each 2- 6 week sprint

Email to ACOR, COR, PM, Tech Lead, and Product Owner

Each Sprint

6.2.1 Specificatio

n Document

Contractor format, Government approved

Last day of each 2- 6 week sprint

Email to ACOR, COR, PM, Tech Lead, and Product Owner

Each Sprint

*Standard Distribution: 1 copy of the transmittal letter without the deliverable to the Contracting Officer and assigned Contract Specialist; 1 copy of the transmittal letter with the deliverable to the Primary COR.

6.3. Task 3 – Production Support for the Telecommunications Contracting. The contractor shall respond to incidents that are generated by the Tier 1 service desk through the Government Trouble Tracking System (e.g.

ITSM). Trouble tickets will primarily fall in the Appian BPM environment, but access and expertise with the connected database (Oracle) and web servers (Apache) will be required as well.