Every "missing information" item surfaced across the four feedback-loop deep dives, deduplicated where more than one loop raised the same underlying question, and ordered by how much answering it would change the accuracy of the eventual Systems Map report.
| # | Gap | Affects | Why it matters | Suggested source |
|---|---|---|---|---|
| A · Cross-cutting gaps | ||||
| A1 | Is there any mechanism, anywhere, that reviews closed/resolved items as a set for recurring themes and reports them upward (to ELT/board)? Incident analysis ends at “Share Any Information and Lessons” with no linked destination; the CI register shows no aggregation step; goal-tracking data terminates in an emailed Excel report with no documented destination. Three unrelated processes hit the identical wall. | Cross-cuttingIncidentCI RegisterClient lifecycle | This is the single highest-value question in the whole engagement — the one thing that, if answered “yes, here's where it happens,” would overturn the central finding of the exec summary. If genuinely “no,” it confirms the pattern and should anchor the Systems Map's core recommendation. | Quality/Practice team, PMO, or whoever owns board/ELT reporting packs |
| A2 | Current operational volume/throughput data across all four processes (incident counts and severity mix; CI register full extract — sample was ~38 of an implied 300+ entries; intake/departure/goal-review counts per month; current $ figures for the 2024-identified funding leakage points). | Cross-cuttingAll four loops | Every loop analysis was built from process design documents or a partial sample, not current operational reporting. Without volumes we can describe the shape of each loop but not its scale or urgency — which materially affects prioritisation in the Systems Map. | Power BI/BI team; Finance; CI register owner; VisiCase/HubSpot reporting owner |
| A3 | Which document generation is actually authoritative where multiple exist. The incident library's filenames (02.0x) don't match internal numbering (03.0x). The client lifecycle has three document generations (Sales Guide 08/23, Client Entry/Exit Procedures 05/2024, To-Be library 11/2025) describing intake differently, with no deprecation markers. The funding loop's Reconcile Payments map is itself marked “OLD MAP.” | Cross-cuttingIncidentClient lifecycleFunding | If the Systems Map is built on a superseded document, the whole deliverable inherits that error. Needs resolving early, not discovered during report drafting. | PMO (document version control); Sarah Archer's nominated point of contact |
| A4 | Whether the M.E. Services assessment (7 May 2026) recommendations are being actioned, and if so by whom and on what timeline. It reviewed the same SIL customer journey territory as our client lifecycle loop and reached a closely aligned “feedback loops don't close” conclusion two months before our engagement mobilised. | Cross-cuttingClient lifecycle (directly)All loops (framing) | Avoids the Systems Map either duplicating M.E. Services' scope unnecessarily or contradicting recommendations Achieve may already be implementing. | Sarah Archer / Tina McManus (both on the M.E. Services distribution list) |
| B · Incident management loop | ||||
| B1 | The severity guide / “conditional logic” referenced in 02.00 and 02.02 for classifying incidents isn't in the document set. | Incident | Materially affects how the whole loop triggers — can't assess triage consistency without it. | Quality Team / Customer, Practice & Quality Team |
| B2 | Whether OCG/Commission responses, once received, are logged anywhere (VisiCase, CI Register, elsewhere) and who owns actioning them. The June 2026 CEO Report shows a live example (four Commission matters open since Aug 2024) with no visible landing process. | Incident | Direct compliance exposure; also a concrete test case for gap A1. | GM Safeguarding Quality / EGM Quality |
| B3 | Rationale for the governance asymmetry between OCG reporting (no review/approval gate before submission) and Commission reporting (mandatory GM review). | Incident | Could be a deliberate risk-based design choice or an inconsistency worth flagging — need to know which before recommending anything. | CEO / EGM Quality |
| B4 | Whether the incident process documents (VisiCase-era, last modified 10 Nov 2025) describe the current process, or whether Connect's “redesigned incident management system” (live 2 June 2026) has superseded them. | Incident | Determines whether this whole loop analysis describes current-state or an already-replaced state. | IT/Connect project team |
| B5 | Whether incident-analysis output feeds the Skills and Competencies Management process (03.01.03) or any training/induction content. | Incident | Tests whether the “learning” half of the loop exists anywhere adjacent, even if not in this process library. | L&D / GM Safeguarding Quality |
| C · Funding / billing / claims loop | ||||
| C1 | Current $ figures for the 2024-identified leakage points ($1.2M pending revenue, $4M AR, $5k/month timesheet leakage, 1,100 open claim errors), ideally measured post-Connect. | Funding | The only figures available are ~19 months old; the single most important input to the funding leakage quantification deliverable. | Finance / Revenue Accountant |
| C2 | Who owns Reconcile Payments now — the source swimlane is dated 18 Nov 2025 and marked “Role TBC” / “OLD MAP.” | Funding | Ownership is the precondition for the loop closing at all. | Finance leadership |
| C3 | Status of the six “not mapped” process endpoints (Accounts Receivable, Finance Reporting, Clearing Process, Payroll Processing, Accounts Payable, Rejection Handling) — mapped elsewhere, or genuinely undesigned? | Funding | Determines whether this is a documentation gap or an operational one. | Finance / PMO |
| C4 | Whether ledger-to-sub-ledger (Business Central ↔ Visicase) reconciliation has been implemented since the 2024 finding, and if automated or still manual. | Funding | Direct test of whether the 2024 remediation actually landed. | Finance |
| C5 | Remediation plan/timeline for the SOS-as-non-searchable-PDF problem, given the CFO flagged it as blocking a named viability metric as of 25 June 2026. | Funding | Confirms whether this is being actively worked or has stalled. | CFO / Finance |
| C6 | Whether the 15 June 2026 Connect payroll bug was a one-off or symptomatic of a broader Connect-to-finance integration issue. | Funding | Tests whether Connect resolved the pre-existing manual-workaround pattern or just relocated it. | IT / Connect project team |
| C7 | Contingency plan for the Irregular Support single-person-dependency risk flagged in the 2024 review (“when she is away no one completes this”). | Funding | Concrete operational risk with a known, unaddressed owner-continuity gap. | Finance / NDIS Admin team lead |
| D · Continuous Improvement (CI) register loop | ||||
| D1 | Does the raiser get notified when their item is completed, if they're not the assigned owner? | CI Register | Determines whether frontline/functional staff trust and keep using the mechanism — the closure note's audience is ambiguous in the data. | Quality/Practice team (register owner) |
| D2 | Full volume and time span of the register (sample was ~38 rows, Jul–Dec 2024, starting mid-sequence at IMP000308, implying 300+ earlier entries). | CI Register | A full extract would materially change confidence in any volume/pattern claim in the Systems Map. | Register owner |
| D3 | Is there a defined escalation path when a CI item is overdue against its risk-rating SLA? | CI Register | The register has due dates but no visible breach/escalation field in the sample. | Register owner |
| D4 | How is a “Not Approved” outcome communicated back to the raiser, and is there tracking of rejected-but-recurring requests? | CI Register | Tests whether rejected ideas simply disappear or get revisited. | Register owner |
| D5 | Is the incident-to-CI feed (evidenced in 2 sampled entries) a defined process step or an ad hoc practice? | CI Register | Determines whether the one cross-loop link that does exist is reliable or incidental. | GM Safeguarding Quality |
| E · Client lifecycle loop | ||||
| E1 | What proportion of intake/profile/record-maintenance cases fall down the manual-fallback branch vs. the automated one at each “Integration? Yes/No” gateway. | Client lifecycle | Direct input to both the funding-leakage and information-flow-mapping workstreams, not just this loop. | Service Development / IT |
| E2 | Is departure data (reasons, patterns, the COO-level decision rationale) analysed in aggregate anywhere? | Client lifecycle | Tests whether the organisation learns from why people leave, or treats each departure as a single-case record. | COO / GM Safeguarding Quality |
| E3 | What actually happens at the point Achieve's own Customer Journey Map marks “undocumented” (the SIL exit trigger)? | Client lifecycle | Self-acknowledged gap on Achieve's own diagram — likely the fastest gap to close since someone clearly already knows the informal answer. | Owner of the Customer Journey Map (likely Marketing/Customer Engagement) |
| E4 | Does the intake process vary by service line (SIL vs Drop-In vs My Life vs My Career), which would explain the discrepancy between the To-Be diagrams and the Client Entry Procedure? | Client lifecycle | Could resolve gap A3 without further escalation if the answer is simply “different service lines, different processes.” | Service Development leadership |