eContents PWS Review.docx

INTERNAL WORKING DOCUMENT — NOT FOR RELEASE

PWS Remediation Guide: Reframing Tasks to Shift Onus to the Vendor Purpose. This document identifies sections of the draft PWS (VA eContent, Digital Books, Professional Development Training and Support Services) that place risk, workload, or ambiguity on the Government where it should sit with the vendor, or that are unenforceable/inconsistent as written. Each item states the problem, why it matters, and suggested reframing. The program office can work these in the interim; the paired RFI is also structured so industry will independently surface many of the same issues, which strengthens the case to fix them.

How to read this. "Onus problem" = the current text obligates or exposes the Government. "Enforceability problem" = the text can't be measured or held against the vendor. "Consistency problem" = internal contradictions vendors will exploit or that undercut credibility.

1. Section 508 deliverables and acceptance (Onus problem — highest priority) Current text commits VA to validate 508 compliance on "a sample of new, revised, and legacy content for each product, modality (content type), role, and/or platform," quarterly, and reserves VA's "right to perform independent testing" before acceptance.

Problem. As written, VA-side review is woven into the acceptance and conformance chain. If the VA 508 team lacks capacity to complete these reviews on schedule, the vendor can argue that acceptance criteria were not met by the Government, or that conformance disputes are VA's fault — potentially voiding or weakening the remedy terms. This over-obligates a small VA team and makes contractor payment/acceptance dependent on VA throughput.

Reframe — shift the affirmative burden to the vendor:

· Make the deliverable the vendor's ACR plus full self-test artifacts (methodology, environment, pass/fail by success criterion) for each product, modality, role, and platform.

· State that acceptance is presumed upon timely delivery of conforming artifacts — it does not wait on VA review.

· Recast VA independent testing as a reserved right, exercisable at VA's discretion at any time, not a precondition to acceptance and not a scheduled obligation.

· Provide that if VA exercises that right and finds non-conformance, the existing no-cost repair/replace clause is triggered within a stated cure period.

· Add a vendor duty to maintain conformance across updates, with regression testing and advance notice of releases affecting accessibility (the draft already has good language for this under "Ongoing Maintenance" — pull it up into the deliverable structure).

Net effect. VA's limited review capacity is decoupled from the contractor's acceptance and payment milestones, while VA retains full enforcement leverage. Coordinate final language with the 508 Program Office and CO.

2. Service Level Agreements — Section 13 (Enforceability problem — high priority) Current text. The "Service Level Agreements" section lists only three qualitative statements: keep current with the latest product version, "proven, industry-leading functionality," and "no failed implementations." There are no actual service levels.

Problem. There are no measurable levels (no uptime %, no response/resolution times, no completion-posting reliability, no credits). Vendors cannot price risk against this, and VA has no graduated remedy between "tolerate it" and "terminate." "Industry-leading functionality" is unmeasurable. "No failed implementations" is discussed separately below.

Reframe — insert real, measurable SLAs with credits:

· System availability: define committed uptime (e.g., a stated monthly %), measurement method, exclusions, and a credit schedule for misses.

· Completion-data posting: define that completions post to TMS 2.0/LMS automatically and within a stated time, with a reliability threshold and credits for failures.

· Help desk response/resolution: define response and resolution targets by severity, with escalation.

· Content update/currency: tie to the currency obligation (item 3 below) with defined timelines and credits.

· Integration failure response: the draft RFI already references a 24-hour detect/respond target for integration process failures — mirror that as an SLA with a remedy.

· Replace "industry-leading functionality" with defined, testable capability requirements or move it out of the SLA section entirely.

3. Content currency — the "commercially unreasonable" escape hatch (Onus problem) Current text. If a course is outdated due to a change in Federal law/EO/regulation, the vendor has 90 days to remedy; if it can't, or "deems it commercially unreasonable to remedy," the vendor notifies VA and the parties "agree to an alternative timeline."

Problem. The "commercially unreasonable" clause is a broad, vendor-defined escape from the core currency obligation, and "agree to an alternative timeline" gives VA no floor. VA could be left indefinitely hosting non-compliant content with no remedy.

Reframe:

· Require interim risk mitigation regardless of remediation timeline: the vendor must flag or suppress the affected content and notify affected learners within a short, fixed window (e.g., a stated number of business days) upon discovery or notice.

· Narrow or remove the "commercially unreasonable" out. If retained, require the vendor to propose a compliant substitute or removal-with-credit, so VA is never stuck hosting non-compliant content without recourse.

· Add an SLA credit (tie to item 2) for content that remains non-compliant past the remediation window.

4. "No failed implementations" (Enforceability + competition problem) Current text. Appears in both the SaaS/security requirements and Section 13 SLA.

Problem. This is an absolute no honest large vendor can attest to, and it functions as a de facto sole-source screen. It is also unverifiable and unenforceable — "failed" is undefined.

Reframe. Replace with a disclosure requirement: "Describe any implementations of comparable scope that did not meet contracted milestones or were terminated, and the corrective actions taken." This gives VA real past-performance signal without an unattestable absolute, and it widens the field. If the program's true intent is a track record of successful large-scale delivery, state that as a past-performance evaluation factor instead of a PWS requirement.

5. "Industry-leading functionality" / "proven functionality" (Enforceability problem) Reframe. Delete or convert to specific, testable capability requirements. Marketing adjectives in a PWS create acceptance disputes and cannot support a CDR.

6. Licensing scope and the FTE / contractor / vendor-support exception (Consistency + onus problem) Current text is internally inconsistent:

· Deliverables table: "250,000 licenses" for "Federal users."

· RFI: "250,000 unique users," with 10,000-license increments.

· Course Content Topics / Performance table: content delivered to "VA's Federal external clients."

Problem. Vendors can't price consistently, and the FTE-only intent conflicts with the need to grant access to non-employee help desk staff, VA support contractors, and vendor support personnel. Left unresolved, this becomes a scope/cost dispute.

Reframe — separate "who learns" from "who administers":

· Define the licensed population as VA-authorized end-user learners (state the FTE-primary intent and the cap).

· Create a distinct, non-consumptive support/administrative access category covering: VA help desk support contractors acting on VA's behalf; VA administrators; and vendor personnel requiring access for maintenance, troubleshooting, and support. Specify that this access is not counted against the licensed learner pool and is provided at no additional cost.

· Pick one consistent user count and definition and use it everywhere (deliverables table, technical requirements, and RFI).

· State the increment mechanism (10,000-license blocks, prorated) once, clearly.

7. Government Quality Assurance / QASP outcomes (Enforceability problem) Current text. The Performance Requirement Summaries "Outcomes" column repeatedly states that damages "may accrue over the course of the contract year and be assessed by the CO on the following option year if nonconformance is identified."

Problem. Deferring assessment to "the following option year" is odd and weak — it delays any consequence, may not survive if an option isn't exercised, and doesn't map cleanly to the FFP CDR/deduction mechanism described elsewhere. It reads as a placeholder.

Reframe. Tie outcomes directly to the mechanisms VA can actually use in-period: CDR issuance, monthly payment deductions for validated nonconformance (already described under Government Quality Assurance), SLA credits (item 2), and CPARS impact. Remove the "following option year" deferral or replace it with in-period remedies.

8. FedRAMP / ATO gating language (Consistency + competition problem — decision needed) Current text hedges both ways: requires current FedRAMP documentation at FISMA-Moderate, but also accepts "willing to obtain within the PoP" and "significant progress." Requires an ATO but accepts "significant progress leading to obtaining the required ATO." Base PoP is only 12 months (Dec 8, 2026 – Dec 7, 2027).

Problem. This ambiguity directly affects the sole-source-vs-competition question. "Authorized at award" may narrow the field to the incumbent; "in process" widens it but raises the risk of a vendor never achieving authorization within a 12-month base. A full agency ATO can take many months. The requirement needs a clear, defensible standard.

Reframe — make a deliberate decision and state it once:

· Decide the minimum acceptable status at award (Authorized / In Process / Ready) and state it unambiguously.

· If allowing "in process," add a hard milestone (e.g., authorization achieved by a stated date) with a remedy if missed.

· Align the ATO expectation to the actual PoP; consider whether reciprocity from prior Federal ATOs is acceptable to accelerate.

· Remove contradictory phrasings so the standard is singular.

This is likely the single highest-leverage item for the market-research/competition determination. Coordinate with the ISO and CO.

9. DISA Impact Level 2 reference (Consistency problem — likely erroneous boilerplate) Current text. Requires "FedRAMP + DISA Impact Level 2 SaaS accreditation."

Problem. DISA Impact Levels are DoD constructs; IL2 is the lowest DoD level and is unusual to cite for a VA (non-DoD) HR/training system. This looks like copied DoD template boilerplate and conflicts with the FedRAMP-Moderate standard cited elsewhere.

Reframe. Confirm with the ISO whether any DISA IL requirement belongs here. If not, delete it and rely on the single FedRAMP-Moderate standard.

10. "NITS — National Institute of Training Standards" (Consistency/accuracy problem) Current text. Acronym list and O&M section define "NITS — National Institute of Training Standards" and require alignment to "NITS requirements."

Problem. There is no such body. This is almost certainly meant to be NIST — National Institute of Standards and Technology. Referencing a non-existent standards body is an accuracy/credibility issue and creates an unenforceable requirement.

Reframe. Correct to NIST throughout, and cite the specific NIST publications intended (e.g., the relevant SP 800-series) rather than a generic "NITS requirements."

12. Live / synchronous VILT scope undefined (Onus problem) Current text. Requires "live events" and synchronous VILT with no quantity, seat, or scheduling bounds.

Problem. VILT is a significant cost driver. Leaving it unbounded means either vendors pad their price defensively or VA faces change-order exposure later.

Reframe. Define what's included in a standard license (session volume, seats, scheduled vs. on-demand) vs. priced separately. Use RFI Section D responses to calibrate.

13. Data return format undefined (Onus problem) Current text. Data Rights section requires return of VA-specific data in "a designated importable file format" but never specifies it.

Problem. "Designated" by whom, and which format, is left open — creating end-of-contract lock-in risk and a transition-out dispute.

Reframe. Specify acceptable export formats for completion records, competency mappings, and catalog metadata, and require the vendor to certify no proprietary lock-in on VA-specific data. Use RFI Section F responses to set realistic formats.

14. Version-control inconsistencies (Credibility problem — fix before any release) Current text. Header says "PWS Version Number: 7.0"; the metadata/source line indicates 7.1; the title block says 7.0; and program correspondence references V8.

Problem. Inconsistent version numbers on a public-facing PWS/RFI undercut credibility and create confusion about which document governs.

Reframe. Establish a single version-control convention, stamp one version number consistently throughout, and retire superseded drafts before posting.

15. Liquidated-damages figure ($37.50 per affected individual) (Accuracy check) Current text. Sets liquidated damages at $37.50 per affected individual for data-breach credit protection.

Problem. This figure derives from VA Handbook 6500.6 Appendix A and has been updated over time. A stale figure creates an enforceability gap.

Reframe. Verify the current figure and credit-protection package against the latest VA Handbook 6500.6 Appendix A before release.

Summary — priority order for the program office

1. Section 508 acceptance/onus restructure (item 1)

2. FedRAMP/ATO gating decision (item 8) — drives the competition determination

3. Real SLAs with credits (item 2)

4. Licensing scope + support-access carve-out (item 6)

5. Content-currency escape hatch (item 3)

6. "No failed implementations" / "industry-leading" (items 4–5)

7. QASP outcomes tied to in-period remedies (item 7)

8. Accuracy/consistency cleanups: NIST, DISA IL2, version control, LD figure (items 9, 10, 14, 15)

9. Undefined scope items: pricing/CLIN, VILT, data-return format (items 11–13) Items 4, 5, 51, and 52 in the paired RFI are written specifically so that industry will independently flag several of these gaps — useful leverage to support the fixes above.