Attachment 6 _ Quality_Assurance_Surveillance_Plan_(QASP)_Proposal_Template_-_APS_20260903.docx

QUALITY ASSURANCE SURVEILLANCE PLAN (QASP) TEMPLATE

Agile Professional Services (APS)

U.S. Army Capability Portfolio Executive Simulation, Training, Test and Threat (CPE ST3)

INSTRUCTIONS TO OFFERORS (PROPOSAL STAGE)

This document is a template for the Quality Assurance Surveillance Plan (QASP). The Government has established baseline performance objectives, surveillance methods, and standard expectations. Offerors are required to review this document and populate all bracketed, highlighted, and designated [OFFEROR TO PROPOSE] fields within their Phase III technical volume. Red text is expected to be updated to align with the offeror’s unique approach. All other text can be updated (show changes in blue text) if it does not align to the offeror’s proposed approach. The finalized, mutually agreed-upon version of this QASP will be incorporated into the contract award.

1. Purpose and Authority

1.1 Purpose

This QASP provides a systematic method for the Government to evaluate performance under the APS contract. Shifting from a legacy, hours-based support model to a dynamic, task-based enterprise capacity model, this QASP focuses on outcomes, deliverables, and sprint velocity rather than full-time equivalent (FTE) tracking.

This QASP defines:

What will be monitored and measured.

How performance standards will be calculated and verified.

Roles and responsibilities of both Government and Contractor personnel.

Surveillance methodologies utilizing real-time digital artifacts.

Contractual remedies, billing adjustments, and corrective action procedures.

1.2 Authority

The Government shall use the methods described in this QASP to monitor contractor performance. The Contracting Officer’s Representative (COR) and designated Technical Representatives (APs/PMs/PLs) will conduct daily, sprint-level, and monthly surveillance. The Contracting Officer (KO) retains sole authority to make final determinations regarding performance failures and contract payment adjustments.

2. Roles and Responsibilities

2.1 Government Roles

Contracting Officer (KO): The sole individual authorized to obligate the Government, modify contract terms, issue formal Corrective Action Requests (CARs), and execute fee or payment deductions.

Contracting Officer’s Representative (COR): Responsible for technical administration of the contract, executing day-to-day surveillance, validating the "Definition of Done," approving monthly progress reports (CDRL A001), and reporting performance deficiencies to the KO.

Product Owners (PM/PL/PdM/HQ Directorate Leads): Act as the Government Product Owners (PO) for their respective backlogs. The POs prioritize user stories in the live tracking tool, participate in sprint planning/reviews, and provide qualitative feedback on task execution.

2.2 Contractor Roles

Agile Program Manager (APM): Serves as the single point of contact for contract execution for their program portfolios. Responsible for Quality Control (QC), updating and maintaining the Agile Performance Dashboard (CDRL A003), and ensuring all deliverables meet the "Definition of Done."

Scrum Master / Agile Lead: Coordinates sprint execution, ensures the cross-functional talent pools are dynamically allocated, manages workflow blockers, and submits the Sprint Reports.

3. Agile Surveillance & Sizing Methodology

3.1 Live Agile Dashboard (CDRL A003)

Surveillance under this contract relies heavily on continuous, real-time access to the Contractor's Agile Performance Dashboard (e.g., Jira/Confluence environment) as mandated by CDRL A003. The Government will have unfettered, role-based visibility to inspect:

Active sprint backlogs, task assignments, and completion histories.

Offeror proposed metrics and active blockers.

Individual task details including estimated vs. actual effort (in hours and proposed measurement methodology (story points, t-shirt sizes, etc.).

3.2 Sizing and Sprints

The contract utilizes a 1-hour user-story increment model as its baseline. However, to forecast delivery velocity and measure performance accurately, the Contractor must propose and maintain a standardized workload-sizing methodology (e.g., Story Points, T-shirt sizing) that integrates with this baseline.

[OFFEROR TO COMPLETE SECTION 3.3]

Offeror Proposed Workload Sizing & Velocity Baseline:

The Offeror shall describe below their proposed methodology for sizing user stories and tasks, and how they will establish and stabilize a sprint velocity baseline within the first 90 days of full performance.

[OFFEROR POPULATE]

Insert narrative describing: 1) Workload-sizing methodology (e.g., modified Fibonacci sequence for story points), 2) Process for aligning story points to the 1-hour baseline, and 3) Formula/approach for measuring and stabilizing team velocity across the PM/PL directorates.

4. Performance Requirements Summary (PRS) Matrix The table below outlines the core Key Performance Indicators (KPIs) and Acceptable Quality Levels (AQLs) mapped to the SOO Performance Objectives.

Offerors must review the AQLs and Surveillance Methods. Where marked [OFFEROR TO PROPOSE], the offeror must supply realistic, highly functional metrics that demonstrate their capability to deliver high-velocity agile services.

Objective 5.1 Agile Enterprise Business Process

Objective 5.1 Agile Enterprise Business Process

Target: e.g., Dashboard active and updated with less than [X] hours latency; 100% role-based permissions active.

Automated audit of Jira/Dashboard logs & CDRL A003 review

Objective 5.1 Agile Enterprise Business Process

Target: Average of [X]% of sprint-committed tasks completed per quarter.

Review of CDRL A003 Dashboard and Sprint Reports

Objective 5.1 Agile Enterprise Business Process

Target: Initial mitigation plan and resource shift executed within [X] hours of notification.

COR verification of timestamped Jira actions and incident reports

Objective 5.2 Acquisition, Financial, & FMS Support

Objective 5.2 Acquisition, Financial, & FMS Support

Objective 5.2 Acquisition, Financial, & FMS Support

Drafting error rate under [X]%; average processing turnaround of [Y] business days.

Monthly audit of DSAMS transaction logs and FMS files

Objective 5.3 Advanced Engineering & Threat Systems

Objective 5.3 Advanced Engineering & Threat Systems

Objective 5.4 Enterprise Ops, Security, & Logistics Tasker Administration & Coordination Enterprise Task Management Software Solution.

(ETMS2)

Objective 5.4 Enterprise Ops, Security, & Logistics

Objective 5.4 Enterprise Ops, Security, & Logistics

Objective 5.4 Enterprise Ops, Security, & Logistics

[OFFEROR TO POPULATE SPECIFIC PRS AQLs] The Offeror shall use the section below to provide the exact metrics and values for the bracketed [OFFEROR TO PROPOSE] fields in the table above. Ensure that proposed AQLs reflect realistic, high-performing service metrics.

Offeror Proposed AQL Targets:

Objective 5.1 - Dashboard Latency: [e.g., "The Jira-like dashboard shall be updated continuously, with no single active task latency exceeding 2 hours."] Objective 5.1 - Sprint Commitment Delivery (Velocity): [e.g., "The Contractor shall successfully complete a minimum of 85% of committed sprint story points/tasks on a quarterly average, as verified by the Definition of Done."] Objective 5.1 - Workflow Disruption Recovery Time: [e.g., "In the event of a simultaneous personnel and task disruption, the parallel off-boarding, talent reallocation, and backlog reprioritization protocol shall be initiated and finalized in Jira within 4 hours."] Objective 5.2 - First-Pass Yield on Requirement Packages: [e.g., "Draft packages (IGCEs, PWS, etc.) submitted to the COR shall achieve a 90% first-pass approval rating."] Objective 5.2 - FMS LOA Turnaround in DSAMS: [e.g., "DSAMS LOA administrative inputs shall be drafted with a zero-error rate, and administrative support tasks completed within 3 business days of task assignment."] Objective 5.4 - ETMS2 Tasker Review Error Rate: [e.g., "The error rate on drafted administrative responses for ETMS2 taskers shall not exceed 1%."]

5. Surveillance Methodologies

5.1 Daily and Sprint-Level Surveillance (CDRL A003 & Jira)

The COR will monitor contractor performance through direct, real-time inspection of the Jira-like digital dashboard environment.

Sprint Planning Reviews: At the start of each sprint, the COR will verify that tasks prioritized in the backlog are properly estimated (sizing methodology) and assigned to qualified LCATs.

"Definition of Done" Verification: The COR will inspect completed tasks in the dashboard environment to ensure they meet the established "Definition of Done" prior to the contractor marking them as complete.

Blocker Log Review: The COR will review active workflow blockers daily to verify that the contractor is actively managing and escalating risks in real-time.

5.2 Monthly Cost and Status Review (CDRL A001)

Billing and labor verification will be directly tied to completed agile tasks. Under CDRL A001:

The monthly cost report must trace every reported cost element directly to its associated CLIN, SLIN, program, or FMS Case.

To substantiate monthly billing and burn rates, each cost element representing agile service execution must reference its corresponding, Government-approved Jira ticket ID (Epic/Story/Task). Any billed hours or story points that cannot be traced back to an approved, completed Jira ticket will be flagged for rejection or payment withholding.

6. Contract Performance Evaluation and Remediation

6.1 Corrective Action Requests (CAR)

If contractor performance falls below an AQL, the COR will issue a formal written warning or a Corrective Action Request (CAR), depending on severity:

Level 1 (Minor Deviation): Issued for isolated failures (e.g., dashboard latency exceeds proposed hours). The contractor must correct the issue within 24 hours.

Level 2 (Systemic Issue): Issued for recurring failures (e.g., sprint commitment delivery falls below proposed quarterly average, or tasker processing errors exceed threshold). The contractor must submit a formal Root Cause Analysis (RCA) and Corrective Action Plan (CAP) within 5 business days.

Level 3 (Critical Mission/Security Failure): Issued for critical failures (e.g., any unstaffed security shift at the SCIF, loss of property accountability, or critical security violation). This triggers immediate escalation to the KO for potential default proceedings or severe payment deductions.

6.2 Proposed Payment/Billing Adjustments

The Government intends to utilize a task-based capacity payment structure. If the contractor fails to deliver the promised capacity or velocity, payments will be adjusted.

[OFFEROR TO PROPOSE]

Offeror Proposed Billing Adjustment Formula:

The Offeror shall propose a fair, standard mathematical formula or methodology for adjusting monthly capacity billings if they fail to meet the proposed Sprint Commitment Delivery AQL or if un-tracked/unsubstantiated labor hours are detected in CDRL A001.

[OFFEROR POPULATE]

Insert proposed formula/methodology. Example:

7. Quality Control Plan (QCP) Summary

[OFFEROR TO COMPLETE SECTION 7]

The offeror must outline how their internal corporate Quality Control Plan (QCP) will monitor, self-identify, and proactively correct performance deficiencies before they reach the Government’s QASP thresholds. The summary must specifically address how the contractor will maintain 100% property accountability, 100% SCIF security staffing, and seamless FMS case administration.

[OFFEROR POPULATE]

Insert summary of the Corporate Quality Control Plan (QCP), detailing: 1) Quality control audits for GFEBS and DSAMS entries, 2) Shift scheduling and backup redundancy plans to guarantee 24/7/365 physical security coverage, 3) Internal inventory checks to prevent property losses, and 4) Peer-review loops for requirements drafting.