Director and procurement review pack
Decision brief for 18 October 2026. Propose an internal, centrally managed review application for about 41 staff, with internal delivery and maintenance.
The decision requested
Approve a capped discovery and design stage. Name the sponsor, product owner, engineering lead, policy decision owners, infrastructure owner, and security reviewer. Reserve 6 person-weeks of total effort over 3 weeks. The planning labor value is $18,000 to $30,000 at the illustrative internal cost rates in the cost model. This is an allocation request, not a supplier quote or a request to deploy the demo with SPII.
At the discovery gate, management receives approved scope, hosting/control requirements, a build-versus-reuse assessment, workflow decisions, baseline measures, and an updated estimate. It can authorize the next stage, narrow the scope, or stop. Procurement confirms whether any hardware, licenses, support, or outside assessment needs a purchase route. Internal delivery does not bypass agency controls.
Confirmed constraints and open sizing inputs
| Input | Status | Planning use |
|---|---|---|
| Review meeting | Confirmed by the project proposer: 18 October 2026 | Use the preparation schedule below. |
| Users | Confirmed aim: about 41 people who directly interface with reviews | Central staff workspace. Verify role, program and region distribution. |
| Data and access | Confirmed: government SPII, internal only, high security | Agency-hosted environment and approved internal network/remote-access paths. |
| Delivery and maintenance | Confirmed: internal staff, retain ownership and keep costs low | Use named staff allocations and an agency-owned repository/services. |
| Peak usage | Assumption: 12 active concurrent editors. Test bursts from all 41 staff. | Measure actual month-end and approval peaks in discovery. |
| Review/document volume | Unknown. The demo can seed 4,800 synthetic reviews but this is not agency volume. | Obtain annual volumes, document size/count, retention, and history scope. |
| Policy/control baseline | Unknown until IT, security and records owners identify it | No claim of accreditation, hosting approval, or legal compliance is made by the demo. |
| Available capacity | Unknown. Proposed capacity is in the staffing plan. | Delivery dates depend on named allocations and approved infrastructure. |
The problem and expected benefit
The legacy reference describes separate review workbooks, file intake tools, shared folders, generated documents, email actions, and an external corrective-action tracker. A central review workspace should reduce repeated entry and make current ownership, evidence, approvals, and report eligibility visible. These benefits are hypotheses until measured with staff.
| Measure | Baseline to collect | Proposed pilot target |
|---|---|---|
| Administration time per review | Timed intake, handoff, document handling and reconciliation work | At least 20% reduction for the agreed activities, without shifting work to another role. |
| Traceability | Fraction of approvals/returns with owner, time, reason and source revision | All tested transitions retain required evidence. |
| Reconciliation | Monthly counts and sampled field/output mismatches | Zero unexplained count or field mismatches at pilot acceptance. |
| Find assigned work | Timed staff journey on actual network | Routine queue/search ready within an agreed performance target. |
| Support and adoption | Help requests, training time, task completion | Named service owner and two maintainers. At least 90% successful completion of agreed UAT tasks after training. |
Targets are proposed management criteria. They are not measured savings. Use the benefit model to calculate the financial implication of observed time savings.
What the demo proves and what it does not
| Observed code capability | Evidence | Acceptance still needed |
|---|---|---|
| Role/program/team checks and protected review commands | access source and save source | Real agency identity, access governance, account lifecycle and security assessment. |
| Versioned snapshots, concurrency checks, transactional projection/event writes | schema and store | Recovery, retention, restricted audit administration, load and migration rehearsal. |
| Versioned SNAP Negative calculation and field checks | calculation and knowledge register | Independent policy validation, dated tables, workbook differences and full approved rule set. |
| Synthetic import, search, PDF attachments and downstream screens | dated status and existing wiki systems | New non-drop routing is blocked by the defect map. Memo delivery/notice production and certified federal submission remain open. |
| EPP adapter fields | EPP/DCA scope | No DCA role, action lifecycle, Access write, or actual corrective-action handoff exists. |
Options for management
| Option | Benefit | Cost or limit |
|---|---|---|
| Keep and improve the legacy tools | Small initial change and familiar operations | Repeated workbook/folder/email coordination remains. Ownership and support effort still need measurement. |
| Use an approved existing agency platform | May reuse identity, hosting, support and purchasing routes | Discovery must compare workflow fit, rule testing, document controls, accessibility, data export, and recurring licenses. |
| Build the proposed internal application | Agency ownership, explicit workflow and integration boundaries | Requires engineering and SME capacity, assurance, support, and staged rollout. Recommended subject to discovery fit review. |
| Promote the demo through broad hardening | May preserve more existing code | Does not match the original intent. Choose only if an independent assessment shows lower whole-life effort and satisfies the same gates. |
Meeting agenda and demonstration
| Minutes | Topic |
|---|---|
| 0 to 3 | Business problem, 41-user scope and decision ask. |
| 3 to 10 | Synthetic demo: assigned work, review, computation save, submit and return. Explain the routing blocker. Show seeded downstream stages with that label. |
| 10 to 16 | Internal architecture, SPII control owners, and deployment boundary. |
| 16 to 21 | Staff capacity, cost model, stage gates and benefits measurement. |
| 21 to 27 | Director/procurement questions using the FAQ. |
| 27 to 30 | Record decisions, owners, evidence needed and next gate date. |
Prepare a synthetic backup walkthrough and a local copy of this wiki if the demo is unavailable. Do not use real records to make the demonstration more convincing. Do not perform database reset, policy publication, external writes, or account edits during the meeting.
Preparation before October 18
| Date | Output | Owner to confirm |
|---|---|---|
| October 5 to 8 | Complete lessons 1 to 4. Identify workflow blockers and source evidence. | Project proposer and policy SME. |
| October 9 to 12 | Confirm available internal staff, agency infrastructure route, security/records owners, and baseline volumes. | Engineering, IT/security, operations and manager. |
| October 13 to 15 | Replace cost-rate and staffing assumptions where known. Review scope and options. Rehearse FAQ objections. | Product owner, finance/procurement and lead engineer. |
| October 16 to 17 | Run synthetic rehearsal, verify links/screens, prepare backup walkthrough and one-page ask. | Project proposer with examiner and supervisor. |
| October 18 | Record approved discovery effort, owners, open conditions and gate date. | Director/sponsor. |
Decision record to complete in the meeting
| Decision | Proposed owner | Result to record |
|---|---|---|
| Discovery authorization and capacity | Director and resource managers | Approved effort ceiling, assigned people, start condition and gate date. |
| Initial scope | QC product owner | SNAP Negative operational pilot and exclusions. |
| Defect map/memo classifications | QC/PEC management | Named approver and delivery date for signed decision table. |
| Internal hosting and identity | Agency IT | Environment/network owner, approved identity service and provisioning plan. |
| SPII and records controls | Security, privacy and records owners | Required assessments and evidence for a real-data pilot. |
| Procurement route | Procurement and finance | Existing services available, purchases/assessments needed, contracts and funding source. |
Use the FAQ, production architecture, roadmap, test plan, and extension plan as appendices.