Delivery and finalization roadmap
Separate demo preparation from the new production build. Deliver one accepted internal SNAP Negative workflow before adding programs.
Finalize the demonstration for October 18
| Work | Owner to name | Acceptance |
|---|---|---|
| Verify the synthetic walkthrough | Proposer + examiner/supervisor | Find, edit, calculate, save, reload, submit and return are demonstrated on known fixtures. Label seeded PEC/CAO stages. |
| Record blocker decisions | QC/PEC management | A signed defect-map work item has code meanings, memo choices, approver and date. Do not remove the guard for the meeting. |
| Check claims and backup material | Proposer + lead engineer | Brief, FAQ and screenshots distinguish current, historical and proposed. Local backup needs no live system. |
| Confirm staff and service route | Resource managers + IT/security | Available internal capacity, hosting/control owners and discovery gate are recorded. |
| Rehearse objections | Proposer + manager | Give the five-minute pitch and answer cost, ownership, SPII and scope questions without unsupported claims. |
This documentation change does not finalize the app or implement the missing integrations. The meeting should authorize discovery, not real-data use. If the defect map arrives, implement and test it as a separate reviewed behavior change.
Production stages and staffing basis
Planning model: 26 delivery weeks, 88 person-weeks before contingency. A person-week is 40 hours. Stages are sequential for this model. Specialist work can overlap inside a stage. Procurement/IT waits and unavailable staff can extend calendar time. See the matching cost and allocation table.
| Stage and elapsed weeks | Effort | Deliverables | Gate and accountable owner |
|---|---|---|---|
| A. Discovery, weeks 1 to 3 | 6 person-weeks | Interviews with all six role groups, workflow/field decision tables, source/data inventory, baseline volumes/time, reuse review, internal platform options, SPII threat/control plan and estimate. | Sponsor approves bounded scope, named staff and risk/decision owners. Policy owners approve enough rules to build a complete slice. |
| B. Platform, weeks 4 to 7 | 13 person-weeks | Agency identity integration, membership/scope model, internal environments, schema/revisions, private object store/scan flow, audit, secrets, jobs/outbox and release pipeline. | IT/security and engineering prove access denials, environment separation, deployment and initial restore. |
| C. SNAP Negative slice, weeks 8 to 15 | 32 person-weeks | Source validation/staging, activation/assignment, household/computation, approved checks/defect map, return/approval, memo and CAO response, approved correspondence subset, reporting and frozen exports. | QC owner completes a newly imported review and a drop with independent expected results. Receiving contracts are approved for any operational output in scope. |
| D. Assurance, weeks 16 to 19 | 16 person-weeks | Independent policy cases, security/accessibility assessment, concurrency/load, failed jobs, migration/recovery rehearsals, records controls, monitoring/runbooks and release candidate. | Security/records owners and QA sign evidence. No unresolved critical/high finding without agency-approved disposition. |
| E. Controlled pilot, weeks 20 to 23 | 12 person-weeks | 5 to 8 representative staff first, then expand if stable. Run the same sampled work against legacy reference and reconcile results. Record task time, defects, support and user training. | QC sponsor accepts benefits/reconciliation and approves expansion. Real data starts only after its control gate. |
| F. Initial cutover, weeks 24 to 26 | 9 person-weeks | Rollout to the approximately 41 review users, final reconciliation, legacy authority cutover, support rota, two-maintainer handover and operating review. | Service owner and sponsor accept ongoing operation. Retire only approved legacy functions after retention and continuity checks. |
Scope of the first operational release
| Include in the initial slice | Exclude or gate separately |
|---|---|
| SNAP Negative intake, assignment, investigation, versioned calculations and approved workflow | Other programs and a generic rule builder. |
| Approved evidence storage, response handling and defined correspondence subset | Every legacy Word/Excel template, a CAO self-service portal and automated email without an approved delivery route. |
| Required staff queues, basic reports and a validated manual export route | Automatic federal API submission or uncertified output used operationally. If certification is delayed, keep the legacy submission route explicit. |
| Controlled pilot continuity and minimum migration/reconciliation | Bulk historic migration, automatic Access sync and DCA replacement. |
| Internal ownership, secure delivery, backup/restore and support | Public access, external SaaS as an assumed production host, and operational AI benefit/policy decisions. |
Decisions that control implementation
| Decision | Owner | Needed by | Evidence |
|---|---|---|---|
| Review code-to-defect and defect-to-memo mapping | QC/PEC management | Stage A gate, before workflow implementation | Decision table with examples, code meanings and signed approval. |
| Defect-free Valid referral, dispute/reassignment, drop extra fields and narrative text | QC policy owner | Before affected stage C acceptance | Approved transitions/field rules with expected test cases. |
| Deadline start event, calendar/holidays, timezone and extensions | QC operations/policy | Before response and correspondence acceptance | Clock rules and boundary cases. Do not copy an unverified legacy 10-day default. |
| Staff/program/team/region permissions and temporary coverage | QC operations + identity/security | Stage B | Membership matrix, provision/offboard process and access tests. |
| Hosting/control baseline, retention, legal hold, backups and support | IT/security/records | Stage A/B, real-data gate | Architecture decision and required control checklist/evidence. |
| Federal output and submission receipts | Statistics + receiving-system owner | Before operational use of output | Accepted samples, rejection cases, version and reconciliation method. |
| DCA handoff and Access field authority | QC/DCA system owners | Before DCA build authorization | Trigger, source memo version, lifecycle, ownership and cutover contract. |
What happens if a gate fails
Keep the affected stage open. Record the failed evidence, owner, fix estimate and the smallest safe next action. Management can narrow the pilot or keep a legacy output path. Do not call a review complete because the UI looks finished. Do not invent policy or raise a performance limit to make a gate pass.
Cutover and rollback
- Choose a limited pilot cohort and the authority for each field/output. Reconcile a known source batch and document inventory.
- Rehearse migration in a disposable copy. Record row counts, business-key matches, checksums, rule bindings, issues, and output totals.
- Define a freeze window, active-work handling, staff communications, and who authorizes the switch.
- Use an agreed final delta import and verify identity/assignments/open work. Retain protected legacy evidence.
- Switch the chosen function to the new authority. Keep legacy submission or mail functions only where explicitly agreed.
- If rollback triggers fire, freeze affected writes and exports. Reconcile every accepted new action before returning authority. Restoring an old backup alone would lose approved work.
- Perform the handover drill: a second maintainer deploys, diagnoses a failed job, restores a test record and documents the result.
Proposed rollback triggers include unexplained report discrepancies, unauthorized access, repeated loss of accepted writes, incorrect calculated outcomes, or an unavailable critical service without a safe workaround. The service owner defines measurable thresholds before the pilot.
Expansion after the first release
Stage G is separately funded and prioritized: DCA/corrective action, SNAP Positive/Supplemental, TANF eligibility/CAR, then agreed MA variants. The order is a proposal, not a policy dependency. Confirm volume, urgency and available SMEs. Use the package contract and incremental effort bands in program expansion.